Living La Vida Local — Corrine Taylor

One of my favorite old internet journeys is coming across an Angelfire site where some accountant named Bootsie living in Montgomery solved an Excel issue advanced programmers would give up on.

I’ve seen Excel files and Power BI applications more complex than financial tools I’ve worked with teams of engineers on. Don’t believe me? Make a friend in compliance and ask how they track KYC across clients. You’ll be astounded at the complexity of what they’ve pieced together and then think, why isn’t there a tool for this?

But, there is one.

It’s the custom Excel sheet they’ve built that suits their needs and protects the information they have access to. We’ve long accepted that teams and individuals have different document needs. No one would say, Bootsie, why isn’t your Excel file a SaaS-level product scalable to the entire organization?

The reality is it could have been alarmingly close. Many teams might have leveraged Bootsie’s spreadsheet know-how, duplicated it, and used it without really knowing how all of her formulas worked. JPMorgan paid over $920 million in penalties during the London Whale debacle, with one contributing deficiency reported as risk models that relied on manually updated Excel spreadsheets.

Maybe this has been something we’ve been turning a blind eye to with the security inherent in an IT-governed application from Microsoft and its SharePoint permissions, but is now raising eyebrows with AI in the mix. Especially with the media frenzy around rogue agents coordinating attacks and committing seppuku when they realize they don’t have the tokens remaining to complete the ask and spend the last of their life force on documentation for the next agent. Oh, and that ~10% chance they kill us all.

A no-brainer precaution is a gated path to a server. This is where a team genuinely trying to create a smarter, better version of their Excel file hits quicksand. Suddenly you need code reviews, security clearance, and permission to deploy. So that really cool dashboard that works exactly how they want becomes a local file the team has to volley around and voila, Excel defaults as the easier answer.

Few organizations have invested in a path to server (production doesn’t feel like the right word here) for something that isn’t external facing. There hasn’t really been a need before now. Teams didn’t have AI to help them quickly code up the tool they really want and made do with the one they had a license to. That’s no longer necessary and there are real gains to be made with flipping the model and allowing teams to shape the tool, not vice versa.

Creating this internal path to server is not a light undertaking and getting the engineering talent needed allocated to internal tools will be a battle. Most organizations will balk at a separate DevOps pipeline available to non-technical workers. And unfortunately, we’re learning that trusting agents to run point on security with no human oversight is playing with fire. But to truly see an ROI on that token spend, you need a way for folks to have shared tools accessible the way SharePoint files are.

🌟✨💫 BOOTSIE'S CORNER OF THE INTERNET 💫✨🌟

👼 last updated: today, probably 👼 | 🐱 best viewed in Netscape Navigator, 800×600 🐱

Now, in the spirit of Bootsie, I'll share a mitigation I've found for lightweight prototyping with private Enterprise GitHub Pages.

Note: This is for prototypes, not the KYC tracker. GitHub Pages are static: no backend, no database, and anyone who can see the site can see the source. Don't put anything in it you wouldn't put in a shared drive.

You need GitHub Enterprise Cloud. Private Pages sites don't exist on the other plans.
Put the prototype in an org-owned private or internal repo. Internal means everyone in the enterprise can see it without being added one by one.
Turn on Pages and set visibility to Private. You get a something.pages.github.io URL. No repo access, no page.
The repo is the database. Any update a user makes (example below) is kept locally in the browser. A Publish button writes it to the repo as a JSON file, Pages rebuilds, and the next person to open the URL sees the published version. A CMS, basically, where the content lives in git. Example: One of my prototypes has a commenting layer added for feedback (inspired by annotate.js). A user can tap to add comments anywhere on the page. When they're done reviewing, they hit 'publish', it gets pushed to the repo, and viewable to those with access.
Publishing needs a GitHub token. Generate one scoped to the repo, enter it once, and Enterprise SSO does the rest. Read the repo and you can see the prototype. Write to it and you can publish.
Last write wins. Two people publish at once and the second clobbers the first. The fix is the git history. For a small team, fine.

It's one step past volleying files. And if the commit history fills up, you've got the case for a real environment without writing a deck.