I've worked in organizations where adding people became the default answer to needing more capacity. I think that assumption deserves a harder look now.
When I joined Saltbox in July 2025 to lead Product Engineering and AI, I was returning to building software as a team of one. I've kept revising my idea of how much I could take on.
Since then, I've built web and mobile apps for our team and members, the systems behind our business operations, and a data warehouse connecting our business tools. The purpose is to make daily work easier, give our team more time to support members, and help entrepreneurs focus on their own businesses.
That experience has changed the questions I ask about capacity. Before deciding that a project needs a bigger team, I want to understand what the team could accomplish with better tools, useful context, and a clear way to check the result.
Learn the tools by building
I didn't share much about my agent workflow while I was developing it. There's plenty of confident advice about AI. I wanted mine to come from building, experimenting, making mistakes, and learning from them.
My dad has owned a construction business for more than 55 years. I've learned from him that knowing your tools is part of learning the craft. Doing good work, finding creative solutions, and staying on budget all take practice. Building with AI has given me plenty of practice and plenty to learn from.
My first experiments with AI coding tools began around January 2023. Over time, I moved through code completion and tools like Cursor and Supermaven, then Claude Code, and now primarily Codex. The change that matters is how much of the work I can give to an agent and what I need to do to make that delegation useful.
At first, much of the value was in help writing code. Now an agent can investigate a problem, work across files, run checks, and inspect the application it has changed. That lets me give more attention to architecture, product direction, and design.
It also means I need to keep revisiting my process. Instructions written to compensate for an older model can become unnecessary overhead. Code written by earlier agents can become technical debt. Keeping the work understandable is part of making the next change easier.
Build for the problem you actually have
Our data platform began with information scattered across business tools. Answering a question could mean opening several applications, downloading reports, and combining the results in Excel. The person doing that work had to know how the records related as well as where to find them.
We already used Convex for our application database. I wanted a separate place for analytical queries, so I started with Postgres, which I knew from previous companies. Our data volume gave us room to begin with a relatively simple design.
The first application-data sync took days. The broader warehouse, including additional sources, took shape over weeks. Agents helped build it and could inspect source data alongside what we had synchronized.
That reduced the amount of information I had to gather manually before checking the work. I could spend more time on how the system should fit together, which definitions it needed, and how people would use it.
The team could now work in a single place with data from multiple sources to measure performance and business health.
There is nothing novel about a data warehouse. What changed was my ability to build one tailored to our needs alongside the rest of the product work. It made a useful project manageable for one person.
Give agents access to the work
A model's ability matters, but so does what it can reach. An agent without the right information can spend a long time reasoning from an incomplete picture.
Connectors give agents direct access to particular parts of a service. When they expose the records and actions a task needs, they can remove a lot of manual work. Browser and computer use matter when the information or interaction is available only through the application, or when the agent needs to see what a person sees.
Take a new marketing page. An agent can read the approved brief and suggest copy changes. With browser access, it can also examine the rendered page, follow the main links, and check whether the next step makes sense. Those are different checks, and both matter before calling the page ready.
I use the same principle in development. Browser access lets agents exercise web flows. Device tools let them inspect mobile experiences. Tests let them check whether a change meets the requirement and keep working when it doesn't.
I've changed my mind about the value of writing tests through this process. They become especially useful when the agent doing the implementation can run them itself. But the test still has to cover the behavior that matters. A passing check isn't proof of everything around it.
Older, complicated code still trips agents up. Rules can be spread across a system, and a change can miss a case that wasn't obvious. Design also needs my close attention. A working screen can still be awkward to use.
The results are getting more reliable. I am increasingly able to delegate implementation while staying involved in the decisions where my judgment matters most.
Put the capacity into something worthwhile
Theo's argument in It's time to go bigger has influenced my thinking. As building becomes easier, it is worth reconsidering what we choose to build.
For a business, that could mean improving its existing product more deeply. It could mean fixing an operational problem people have accepted as part of the job. It could mean trying an idea that previously seemed too expensive to justify.
Running lean also requires deciding what to stop and what to simplify. More generated code or more completed tasks won't help much if they add complexity without making the business better.
I think leaders owe their teams an opportunity to revisit the work they've ruled out. Pick a customer problem or product improvement that has stayed on the list because the team seemed too small. Define a useful result. Give the team the context, tools, and means to verify it. Then start building with the team you have.
Further reading
- Theo, It's time to go bigger, a video about reconsidering what becomes worth building.