What follows isn’t a proven framework. It hasn’t been battle tested in production. It’s a direction I’ve been thinking about — born directly from the patterns I described in Part 1. Take it as a proposal, not a prescription.
The Smallest Viable Unit
Every problem in Part 1 traces back to the same root cause:
- people making decisions couldn’t evaluate what was being built.
- Vendors exploited that gap.
- No-code platforms obscured it. And eventually the IT manager ran out of roads.
So what’s the minimum viable team that closes that gap — without blowing the budget?
I think it’s three.
One Business Analyst
One Developer
One AI Agent
I call this "TripleOne" — the smallest unit capable of delivering real enterprise high quality in house software in a budget-constrained environment.
The Three Roles and Why Each One Matters
The Business Analyst is not just someone who talks to users. In this model, the BA is the translation layer between user chaos and developer clarity. Users don’t know what they want in technical terms — they know what problem they have. The BA’s job is to capture that, structure it into clear requirements, and protect the developer from scope creep and moving goalposts. Without this role, developers build the wrong thing precisely and efficiently. With it, every build starts with a shared understanding of what done actually looks like.
The AI Agent writes the code. This is what makes TripleOne modern and distinct from just “hire a small team.” A competent developer paired with AI can produce what used to require three to five engineers. The agent handles boilerplate, accelerates implementation, and reduces the time between requirement and working software dramatically. This isn’t hypothetical — it’s already how the best lean engineering teams operate today.
The Developer is not just a coder in this model. The developer is the technical conscience of the unit. They oversee what the agent produces, make architectural judgements, catch what AI gets wrong, and ensure the system is maintainable by the next person who touches it. This is precisely the role that was missing in Part 1 — someone who can actually evaluate output, ask hard questions of vendors, and know when a six figure estimate for an S3 hosted form app is absurd.
Together these three roles directly answer the failures from Part 1. The information asymmetry shrinks because technical oversight is built in. The vendor dependency reduces because the team can build in-house. The no-code ceiling disappears because the team writes real code with real architecture.
One Platform, Not One App
The “one app” in TripleOne is probably the most important thing to get right — and the easiest to misunderstand.
It doesn’t mean you build one thing and stop. It means you build one centralised platform that everything else grows from.
Here’s what that looks like in practice.
The platform starts with an Auth Module — a single source of truth for user identity and role based access control. Every module that gets added inherits this. Users are authorised once, centrally, with clear permission boundaries. No more separate login systems per tool, no more credential sprawl, no more security audits that produce uncomfortable silences.
The frontend is a NextJS/React application built and hosted on S3 — simple, fast, very cheap to run, and easy to extend. Built on JAMstack principles, it separates the presentation layer cleanly from the business logic. Adding a new user-facing module means adding to this application, not spinning up something new from scratch.
The backend uses serverless functions for the API layer — scalable by default, again, very cost efficient at low to medium load, and straightforward to reason about. One SQL database handles relational data. Object storage handles files and assets. Roles and responsibilities are clearly separated at every layer.
When a user requests a new application, the answer isn’t “find a vendor” or “let’s see what Power Automate can do.” The answer is: add a module. One new frontend section. One new set of backend functions. Plugged into the same auth, the same database structure, the same deployment pipeline.
The platform compounds over time. Every module added makes the next one faster to build. The architecture stays coherent because one developer is making the judgement calls throughout. The BA ensures every addition is grounded in what users actually need.
What This Solves — And What It Doesn’t
TripleOne isn’t a silver bullet. A few honest caveats before anyone tries to implement this.
It requires the right developer. Someone who can work with AI effectively, make sound architectural decisions, and resist the pressure to cut corners when timelines tighten. That person exists — but finding them matters enormously.
It requires organisational trust. The IT manager, the department head, the budget approver — someone in the chain needs to believe that one developer with AI can outperform a vendor team. That’s a cultural shift, not just a technical one. In many enterprises, it’ll be the hardest part.
And it doesn’t fix the oversight problem on its own. If the same non-technical manager is still approving scope and signing off on delivery, some of the information asymmetry remains. TripleOne works best when the developer has a direct line to stakeholders — not filtered through layers of people who can’t evaluate what they’re seeing.
Why I Think This Direction Is Worth Exploring?
Enterprise software doesn’t have to be expensive to be good. It doesn’t require six vendors, a no-code platform hitting its ceiling, and a backlog full of things users were told to do manually.
The tools exist today to build maintainable, secure, scalable applications with a team this small. AI has genuinely collapsed the minimum viable team size for software delivery. The architecture patterns are proven — startups have been building this way for years.
What’s missing in most enterprises isn’t budget. It’s the belief that a leaner path is possible.
TripleOne is my rough attempt to sketch what that path looks like. It needs refinement. It needs people smarter than me to poke holes in it. It needs someone brave enough to actually try it.
But every framework starts as someone’s half-formed idea written down.
Top comments (0)