Background
Ryan had been running the agency for five years. The first three years, he thought of the infrastructure ramp-up as inevitable — just the cost of doing software work. In year four, he started tracking where time actually went. The numbers were uncomfortable. On a typical eight-week engagement, roughly two weeks were going to work that was identical across every project. Auth. Stripe setup. SEO metadata and sitemap. Deploy configuration. None of it was creative, none of it was differentiated, and none of it was what the clients had hired them to build.
The challenge
The agency's reputation was built on shipping quality products on time. Ryan couldn't cut the infrastructure work — clients expected production-ready auth and billing — but he also couldn't keep absorbing two weeks of invisible cost on every project. He needed a foundation the team could adopt project-to-project that would let them skip to the product work on day one, without sacrificing quality on the foundations.
How they built it
The first project: a side-by-side comparison
Ryan ran the first ShipAI project in parallel with a traditional engagement so he could compare timelines directly. On the ShipAI project, the team was writing product-specific code by the end of day two. On the traditional engagement, they were still configuring auth on day six. The comparison was stark enough that Ryan decided to standardize on ShipAI for all future work.
Client-specific customization without starting over
The concern Ryan had before adopting ShipAI was whether a shared foundation would be flexible enough for clients with different requirements. One client needed SAML SSO. Another needed a custom billing model with usage-based pricing. Another needed multi-region deployment. All three were achievable by extending the existing foundation — not replacing it. The core patterns held across all three.
SEO infrastructure that clients expect but don't see
Every client product Meridian ships needs production SEO: metadata, sitemap, structured data, canonical URLs. On previous projects, that was week-two work — unglamorous, unbillable in spirit even if technically billable, and easy to do wrong. With ShipAI, it's inherited on day one. Ryan's clients now pass Google's Rich Results Test before the product is finished. None of them ask about it — they just expect it to be right.
A repeatable system across the team
Standardizing on one foundation meant Ryan's team stopped making infrastructure decisions project by project. New developers on an engagement could read the existing patterns and follow them. Senior engineers didn't spend time explaining architecture choices they'd made on the last project. The institutional knowledge lived in the codebase, not in people's heads.
Outcomes
Two-week infrastructure sprint eliminated
Across all projects since adoption, the agency has recovered approximately two weeks per engagement that previously went to infrastructure setup.
Product work starts on day two
On every ShipAI-based project, the team is writing client-specific product code by the end of the second day. Previously this happened in week three.
Margin improved without raising rates
Ryan didn't change what he charges clients. He recovered two weeks of cost per project. That goes directly to margin.
Junior developers productive from day one
New team members on an engagement can follow the existing patterns without extensive onboarding. The codebase is consistent across all projects.
In their own words
Clients don't see the infrastructure work. They see the product. When the product takes the same time but costs us two weeks less to build, that's margin we didn't have before. We haven't raised our rates. We've just stopped paying for work that was invisible to everyone except us.
“We've shipped seventeen client products. The first two weeks of every engagement used to look the same: auth, billing setup, SEO plumbing, deploy pipeline. Now we skip all of it and go straight to the product. Clients don't notice — they just get their thing faster.”
— Ryan Castellano
Frequently asked questions
How does Meridian handle clients with non-standard requirements?
The foundation is extensible. Ryan's team has added SAML SSO, custom billing models, and multi-region configurations on different client projects. The core patterns hold across all of them — clients with unusual requirements need custom work on top of the foundation, not a different foundation.
Does using the same foundation make client products look the same?
No. The product logic and UI design are entirely client-specific. The foundation handles infrastructure — auth, billing, deployment, SEO plumbing. What clients see is entirely custom. What the team builds on top of is consistent.
How does the team onboard to a new client project?
Clone the foundation, update environment variables and branding, then read the client's product spec. Because the patterns are the same across all projects, a developer who's worked on one engagement can be productive on the next one within hours.