In short bursts between work and kid logistics over the course of a few hours the other day, I built a replacement for a janky Google Sheet for internal project staffing, exactly tuned to how Earth Genome operates. And by “I”, I mean I occasionally jumped over to my laptop, prompted Claude and then Cursor, and in between pondered what it was coding up at my direction.
There’s nothing extraordinary about that these days, but I did notice a useful and maybe under-exposed pattern of AI coding usage. Running any organization, there’s usual work motions for planning projects, budgeting, people management and many other things. For a small coding centered organization like ours, there’s not a great fit in existing tools to help us structure our decision making and tracking on these topics. AI coders can make building small, fit for purpose internal tools quick enough to justify the time spent in a small organization.
My usual motion is to build a Google Sheet. I love a good Google Sheet. Built in collaboration, rapid to implement a structure and to enter data, apply filters and sorting, formulas for simple calculations, formatting etc etc. But when there’s any kind of slightly complicated relationship between the data elements with chains of references, or a need for a variety of views, it very quickly becomes a brittle time investment.
That’s exactly what I faced last week. For making decisions on resource allocations for work this year, I created a sheet to list all the projects, associated roles, rough level of effort and timing, and who might be doing what. This is meant to be very coarse and just enough details: months-length level of effort, quarterly timing, no specific tasks but role level assignments. The sheet captured all that, but when I shared it with the team, it failed to easily inform answers to essential questions like ”Is there a good distribution of work across the team? Who’s over-stacked? Where and when do we need more help?”. Typical move at this point would be to revise the sheet a bit, and then take on the extra mental load of connecting the dots in shared notes and live chats.
This moment reminded me of days back at Mapbox. We had a delightful set of internal tools, pulling together React applications, Sheets for data storage, GitHub Actions and lambdas to trigger homemade deployment tools. One we used a lot on the Community team tracked donation matching and volunteer opportunities with supported partners, sign ups for Mapbox employees, and recognition of volunteers. After it was initially set up, I took over maintenance of it, and occasionally went down coding rabbit holes getting it to respond to new needs. With everything else on my plate, there was a limit to what I could do, and some weird sore points developed like not being able to easily hide employees who had left Mapbox. From time to time, we’d look at purchasable solutions on the market, and there were quite a few, but they were priced way out of reach of even a medium sized company like Mapbox. The precious budget we did have we wanted going directly to impact. So those tools limped on during my tenure, though I’d be surprised if they’re still going and they haven’t reverted to just Sheets.
Also reminds me of LazyWeb in the rosiest days of the blogging and Twitter era, where we’d send our ideas out into the world and maybe trigger someone else’s creative impulse.
Maybe that kind of development and maintenance burden is gone now with coding agents. LazyAI? It’s been wonderful to follow Simon Willison again and all of his creative experimentation, including his own personal collection of small tools. What about group small tools? I decided to try this and go for more on our resource allocation use case. I shared a description of the need similar to the above, a CSV of the sheet, and a few parameters like using NextJS and Vercel, asked for a plan. The first result was entirely plausible, with a decent enough data schema, a basic UI for viewing and editing closely mirroring the data structures, and an import process for the CSV. To reduce set up needs to start, I told it to store data in the browser in LocalStorage. Later, I had it built an optional Supabase db backend, and Google authentication, along with instructions for me to configure and gather configuration variables, and this was all a breeze. It’s really no challenge for AI coders to build these kinds of CRUD based apps with lightweight service backing.
For our needs, this first quick iteration all basically worked, though was not really an improvement over the Google Sheet. The “right” information was not presented clearly and concisely, and common actions like creating and assigning a project took jumping through too many config screens. That’s where rapid iteration based on a (meaning my own) strong “product” opinion proved helpful. I could ask for different colors to signal areas that need attention like over assigned team, layouts that incorporated visual hierarchy and alignment (like a quarter column dominant table that flowed through all views) simplified edit flow to happen inline and across data types, evolution on data types as new calculations were needed (like adding a contractor flag), and Earth Genome branding. Once it felt good locally, took guidance to put all the supporting services together, and then shared with the team, and took their feedback and rapidly iterated again.
It wasn’t all smooth sailing. The AI got stuck on some really funny things, like building an elaborate routing apparatus to make our logo show up on the login page, when simply placing it in the public folder was enough. These were times when I jumped in and got extremely specific on implementation, or just did it myself. And I’m sure the resulting code is not particularly DRY, has a lot of convoluted flows, but it really doesn’t matter. It’s not going to get complicated enough to become a tech debt, the agent can probably figure it out, and I could just ask for some refactoring advice. I did get better as I went on defining the problem, and I think possible I could up front direct the agent toward better development patterns, and more fine tuned UI/UX.
The hardest part of the whole thing was stopping. The allocation tool reached a good enough point after a few hours. We started using it right away, and with some resistance, turned my attention to all the other work. Then later in the week, I decided to take a plunge again on a BD tracking tool for managing grant proposals and relationships. Similar pattern, and I had to discipline myself to stop building. It was so responsive and fun. Hutch said I had reimplement Salesforce. Not quite! But it was a CRM on our terms, in a way that was highly simplified and customized to our peculiar needs, and in line with our ways of building generally, so easy enough for us to maintain. The alternative really was not doing anything.
AI coders are going to make these small tools for small orgs feasible. Some quick searching identified whole new companies and products emerging in the last six months that will pre-assemble all these supporting services (auth, db) and UI/UX patterns, and build “enterprise” tools. More than we need, but I can see the appeal. I think I even spotted a Super Bowl commercial for Salesforce where “everyone can build apps”.
One thing I’ve learned in helping “everyone” to make maps is that reducing the technical accessibility doesn’t ultimately mean everyone, but creates a new specialization in reaching high fit to purpose. I expect the same here, where the critical skill becomes identifying the right use cases and having strong opinions on the right experience, while steering to easy-to-leverage supporting services and technical frameworks. This approach feels promising not only for internal tools, but in rapid definition and prototyping of niche operational and decision support needs in nature and climate. I wouldn’t put something this haphazard in full production, but it’s a high value pattern for defining the right solution with subject experts to build one (or many) to throw away before implementing a full release.
If you’ve read this far, expect some of this resonates. Would love to hear more, drop me a line.
.png)
.png)


