How we ship production software fast
A full SaaS — auth, billing, scheduled monitoring, AI features — shipped to production in weeks, not months. Here is what makes that pace possible, and what we would do differently.
Lintry — our own website QA SaaS — went live in production a few weeks after we started. Authentication, Stripe subscription billing, scheduled background jobs, AI-powered explanations, public report sharing, team accounts, transactional emails. The standard "this takes six months" feature set.
We did not get there by working harder. We got there by changing what "doing the work" means.
The compounding leverage of modern tooling
There is a tempting narrative where someone claims "AI built my SaaS in a weekend," you click expecting genius, and find a no-code app with three screens. That is not this.
Lintry is a real Next.js application — thousands of lines of code we designed, wrote, and own. The shift is not "AI wrote our code." It is that AI-native tooling sits in the loop for almost every meaningful decision, and that loop compounds.
Concretely:
- Architecture decisions get pressure-tested before they are committed
- Schema migrations get reviewed before they run
- Edge cases get surfaced before they bite
- Documentation gets written alongside the code, not after
- Test coverage gets generated for the parts humans tend to skip
Each of these is small. Compounded across a whole build, the saved hours add up to weeks.
What we cut to move fast
We cut features ruthlessly. The launch version had:
- One scan type
- One alert channel (email)
- Three pricing tiers (no agonizing over tier design)
- One report layout (no customization)
Everything else we deferred: agency branding, Slack notifications, API access, white-label reports, scheduled scan windows, multi-language support. All of it has a place on the roadmap. None of it was needed to answer the only question that matters at launch — will real customers pay for this.
Most teams get MVPs backwards: they keep the easy stuff (a settings page nobody uses) and cut the hard stuff (the actual core feature). We did the opposite. The scan engine was overbuilt for launch. The settings page barely existed.
What we would do differently
Three things, in order of impact.
1. Get billing live earlier. Without billing, you cannot answer "will people pay" — the only question that matters at this stage. Ship it in the first couple of weeks, not halfway through.
2. Write the cancel flow on day one. Counterintuitive, but the cancel flow tells you what data you are committing to own, and how much pain a paying customer goes through to leave. Designing it last is how you trap yourself into bad data architecture.
3. Skip the marketing site at first. We spent early days on a landing page and threw most of it out once we understood who was actually buying. Build the product, show it to real people, then write the page.
The takeaway
A small senior team with modern tooling ships more software than larger teams could a decade ago. The leverage is real. The bottleneck has moved from "can we build it" to "do we know what to build" — which is exactly why we start client engagements with Discovery.