Big App, Small Model
Agentic production coding isn’t about using the biggest model. It’s about scaling AI by flattening the software complexity curve.
For years, our obsession has been the big app, small team model: flattening the software complexity curve so small teams can build production cloud applications with an expertise-first and scale-first mantra. Those lessons, that expertise, and those workflows have become so relevant in the era of Agentic Production Coding that now we can build a big app with small models.
If we really want to scale AI, price is now the new bottleneck. With the right technique and good engineering discipline, we can make AI a force multiplier, not the wallet crusher.
In other words, engineering has been reshaped, but it’s still engineering and good engineering is still what matters for quality and scale. The goal is to avoid the common trap of delegating too much and make sure we still have a strong foundation to multiply from.
1. The trap: buying your way out of expertise
There’s a quiet wish underneath a lot of AI enthusiasm right now. It goes something like:
Maybe we don’t need the expensive expertise anymore. Maybe we don’t need people who understand architecture and what makes applications scale. The AI will figure it out, and if it can’t today, it’s just a not-yet problem.
If we take that train of thought, we reach for the biggest model we can find, and the biggest-model chase starts. The focus moves from augmenting expertise to delegating expertise. The bigger the gap we ask the model to fill, the bigger the model we think we need.
For demos, this works extremely well now. We one-shot an MVP, add a couple of iterations, and feel like we’re at production level. When issues show up, we call it a not-yet problem and wait for the next new-awesome-frontier model.
But production has never been about one-shotting anything. It is about architectural discipline, tradeoffs, and understanding which track we want the system to follow and why. That requires expertise, plus a huge amount of unwritten experience and context.
The real opportunity in a production system is managing complexity as it grows, then taking the steps necessary to keep that complexity from becoming unmanaged. AI can absolutely force multiply that work, but only when there is a strong foundation to multiply from.
That is where a robust, scalable blueprint from the start becomes the game changer. If we skip it, we accumulate a photo collage of technology: a little framework here, a database there, a shiny tool from LinkedIn, all easy in the moment and none chosen because it belonged. Complexity does not grow linearly here. It grows exponentially.
In other words, scaling engineering with AI is still about flattening the complexity curve as the system and requirements scale.
Look at the red line, easy first. It starts low and cheap, then curves violently upward. The blue line, architecture first, starts a little higher because we invested up front, but it stays flat as we scale. And the green line beneath it? That’s the blueprint doing its job, pulling the whole system down toward manageable.
The choice isn’t “big model versus small model.” It’s managed complexity versus unmanaged complexity. And that’s a choice we make with architecture, not with a bigger GPU bill.
2. What managed complexity actually looks like
Let’s make this concrete. Say we want to build a video annotation platform, the kind of thing where surgeons review procedure footage, mark moments, and have the system run AI recognition on individual frames. At a high level, we need a few services:
downscaler - Downscales video from HD to 480p, or even smaller, for fast scrubbing.
framer - Extracts images at 4fps or lower for AI analysis, UI annotation painting, and related workflows.
ai-oob - Identifies out-of-body frames for PHI redaction when the camera is outside the body.
ai-in-body - Segments entities when the camera is inside the body, for example tools and organs.
Then we need one or more user-facing web services, whether API or UI:
main-ui - UI annotation tools that allow clinicians to annotate and assess surgical procedures.
devops-ui - Internal DevOps web UI to manage cloud services and related operational workflows.
From a high-level standpoint, there are two very different ways to tackle this.
1) Spider Web Architecture - Unmanaged Complexity
In this approach:
all services talk to each other as needed
communication happens through gRPC for maximum performance
the data pipeline is fixed in some format with a cloud-dependent executor
It feels natural, each service just talks to whoever it needs. With three services, it’s fine. By the time we have fifteen, we’ve built a spider web: every service has to know about every other service, and each new one we add potentially wires into all the rest. Connections grow with the square of the number of services. The fifteenth service isn’t one more connection, it’s fourteen more. That’s the red curve, live.
And because this, or some form of it, is relatively common in smaller applications, AI will probably gravitate toward it. Then it doubles down, triples down, and unmanaged complexity skyrockets.
2) Bus Architecture - Managed Complexity
All services talk to the bus only.
Communication can be as simple as valkey-stream, a lean Redis/Valkey-style stream.
Separation of concerns is handled through app, data, and system event types.
Message payloads stay small, mostly actions and S3/DB UUIDs.
The data pipeline is event based, not map based, allowing us to independently scale job workers without changing other services or hardcoding pipeline rules.
With this architecture, every communication path points straight down into one thing: the bus. Web servers, the command pod, services 1, 2, and 3, none of them talk to each other. Messages are kept very light by design, and even the data pipeline is event based rather than map based, giving the whole system more scale and flexibility.
Now complexity is managed from the start, and AI can do its magic without adding unnecessary complexity to the system.
When we push this further, we can have a full blueprint that frames the work for AI, no matter which model or model generation we use, so it builds inside a robust and scalable application architecture.
Here’s the same idea grown into a real system. Web, mobile, and API access up top. Front-facing web servers and a fleet of worker pods. The message bus in the middle. Kubernetes underneath, auto-scaling those workers because they’re decoupled and stateless. Prod DB is RDS Postgres. Blob storage is S3. Nothing exotic. Every box earns its place.
That’s managed complexity: decoupled communication and small data. Two decisions, made deliberately, that keep the curve flat.
Software is a game of orders of magnitude. Shrink the payload by 1000x and we’re not optimizing, we’ve changed the entire frame of reference for what the system needs to be.
3. Why this is exactly what AI wants
Now bring the small model back in.
When we manage complexity, we relentlessly drive unnecessary complexity toward zero. When we do not manage it, we do not even know the ratio. We cannot tell which complexity is real and which is self-inflicted.
And this is precisely where a smaller, cheaper model thrives.
When the architecture is simple, small messages, one communication pattern, clear contracts, boring proven tools, the model is not being asked to hold a spider web in its head. It is writing a worker that reads an ID from a stream, fetches an object from S3, and writes a row to Postgres. That’s a bounded problem. We do not need a frontier model to nail it. We need a competent one working inside good constraints.
The reason we often believe we need the biggest model is that we are asking it to operate inside an unmanaged system, to reason about a codebase where everything is coupled to everything and any change ripples everywhere. Of course that needs raw horsepower. We made the problem exponentially hard.
Flatten the complexity curve and we shrink the problem the model has to solve. A simple architecture is the great equalizer for models. The blueprint does the heavy lifting so the model does not have to.
That’s the whole thesis in one line:
The blueprint is what lets a smaller models build a big production application.
And best of all, the same discipline makes bigger models perform better too. At the highest level, this is not really about small models versus big models. It is about getting the most out of AI for production coding and deployment.
4. The takeaway for people who build
For a CTO, an architect, or an engineer thinking about where AI actually fits, a few things are worth holding onto.
Code architecture, not PowerPoint architecture. The blueprint that matters is not the PowerPoint diagram. It is the real structure of the running system: what talks to what, and what moves between them. Crystallize that, and everything downstream gets easier.
Lame is the new cool. Choose fewer technologies, and choose boring ones. Default to Postgres for metadata and relational state. Use specialized storage only for specific needs, for example true big-data workloads. Use S3 for blobs. Use one bus. valkey-stream is simple and scalable. Every additional technology is a permanent tax on complexity. The goal is the right tech in the right place, and as little of it as possible.
Dumb is the new smart. Each service should be smart at one thing and dumb at everything else. Services know how to feed themselves, do their job, save their state, and emit events back to the bus.
Keep it small. In the bus, storage, contracts, and everywhere else, keep payloads small. Bus events should carry actions, metadata, and storage UUIDs, not large objects. Adding large payloads to the bus creates a whole slew of unnecessary complexity.
Then, and only then, bring in AI. A small model inside a clean architecture will out-build a big model drowning in an unmanaged one, every time.
The industry is chasing bigger models to one-shot its way past the need for expertise. It is the wrong race. The teams that win will not be the ones with the biggest model. They will be the ones with the flattest curve.
Big app, small model. It starts with the blueprint. Simple always scales better.
BriteSnow builds production cloud applications with small teams and the right architecture. More on flattening the complexity curve at stack.britesnow.com.