Market Signal
Why We Start Every Engagement with Foundation First
Most teams ship features before they've built the foundation. Then they spend years paying for that decision. We don't think that's inevitable.
When a new client comes to Victory Square, the first thing they usually want to talk about is features. The roadmap they have. The product they’ve been planning. The thing they’re trying to ship.
That’s a reasonable place to start. But it’s not where we start.
Before we write a line of application code, we establish the foundation. That means CI/CD. Automated testing infrastructure. Deployment pipelines. Security defaults. Observability. The things that aren’t features but make every feature possible.
This isn’t instinct. It’s a lesson we’ve learned over a decade of building with clients who skipped it.
What “Foundation First” actually means
Foundation First isn’t a philosophy. It’s a sequence.
In the first phase of any engagement, we ask: what has to be true before we can ship reliably? What infrastructure needs to exist? What processes need to be in place? What guardrails prevent a bad day from becoming a disaster?
The specific answers vary by project. A greenfield SaaS product has different foundation needs than a system that’s already in production. But the categories are consistent:
Delivery infrastructure. Can the team ship code safely, quickly, and repeatedly? Is there a CI/CD pipeline that runs tests before anything reaches production? Is the deployment process fast enough that developers actually use it instead of working around it?
Quality infrastructure. Are there automated tests? Is there a meaningful definition of “done” that includes test coverage? Is there a way to catch regressions before customers do?
Observability. When something goes wrong in production (and it will), can you understand what happened? Logs, metrics, alerting. Not because you’ll need them today, but because you’ll need them the first time a user reports a bug at 11 PM.
Security defaults. Are secrets managed properly? Are dependencies audited? Is access controlled by role? These are not things you want to retrofit after you’ve already shipped to real users.
The cost of skipping it
Most engineering teams don’t skip the foundation because they want to. They skip it because they’re under pressure to show progress, and CI/CD doesn’t show up in a product demo.
The math looks good in the short term. You ship features faster. The roadmap moves. Stakeholders are happy.
Then, about six months in, the debt starts compounding. Every new feature takes longer because the codebase is harder to navigate. Every bug takes longer to diagnose because there’s no observability. Every deployment is a small gamble because there’s no automated verification. The team is moving slower than they were in month two, and nobody can explain exactly why.
We’ve stepped into engagements in that state. It’s fixable. But it costs time and money that didn’t need to be spent.
AI makes this more important, not less
One thing has changed about this conversation in the last two years: AI-assisted development makes Foundation First even more critical than it used to be.
When AI agents are generating code, the volume of code produced goes up substantially. If the foundation is weak, the pace at which technical debt accumulates goes up with it. Agents don’t know which corners you’ve cut. They build on whatever foundation exists.
The flip side is also true: a strong foundation gives agents better leverage. When the CI/CD pipeline runs automatically, agents can iterate faster. When the spec is the source of truth, agents can generate code that matches the intent. When observability is in place, agents can help diagnose failures.
Foundation First isn’t a constraint on AI-assisted development. It’s what makes it sustainable.
How long it takes
The honest answer is: less than you’d expect. In most engagements, we can establish a solid foundation in the first two to three weeks. That’s not a universal guarantee (complex existing codebases take longer), but it’s a reasonable expectation for greenfield work.
The investment pays back before the first feature ships. By the time the first real user story is in review, the team has the infrastructure to ship it cleanly, verify it automatically, and observe its behavior in production.
That’s the starting point. Everything that follows is faster because of it.