← All posts
·6 min read

How we shipped Lintry in 45 days, solo

A full SaaS — auth, billing, AI features, scheduled monitoring — built by one engineer in 45 days. Here is what made it possible, and what we would do differently.

EngineeringAI-firstLintry

Lintry launched in production at the end of week six. One engineer. No outsourcing. Full SaaS — authentication, Stripe subscription billing, scheduled background jobs, AI-powered explanations, public report sharing, team accounts, transactional emails. The standard "build this in six months" feature set.

We did not do it by working harder. We did it by changing what "doing the work" means.

The compounding leverage of AI in the loop

There is a tempting narrative where someone writes "AI built my SaaS in a weekend" and you click expecting genius and find a no-code Glide app with three screens. That is not what this is.

Lintry is a real Next.js application with 14,000+ lines of code we wrote and committed. The change is not "AI wrote my code." The change is that AI is in the loop for almost every meaningful decision — and that loop compounds.

Concretely:

  • Architecture decisions get pressure-tested before commit
  • Schema migrations get reviewed before they run
  • Edge cases get listed before they bite
  • Documentation gets written alongside the code, not after
  • Test coverage gets generated for the parts that humans skip

Each of these is small. Compounded across 1000 commits, the saved hours add up to weeks.

What we cut to ship in 45 days

We cut features ruthlessly. The launch version of Lintry had:

  • One scan type (full website)
  • One alert type (email)
  • Three pricing tiers (no haggling over tier design)
  • One report layout (no customization)

We deferred everything else. Custom branding for agencies, Slack notifications, API access, white-label reports, scheduled scan windows, regional content checking, multi-language support. All of it has its place on the roadmap. None of it was needed to validate "can we sell this product to real customers."

The thing most teams get wrong on MVPs is 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 is overbuilt for the launch version. The settings page barely exists.

What we would do differently

Three things, in order of impact.

1. Get billing live earlier. We shipped Stripe in week 4. Should have been week 2. Without billing, you cannot answer "are people willing to pay" — which is the only question that matters at this stage.

2. Write the cancel flow on day one. Sounds counterintuitive. But the cancel flow tells you what data you are committing to ownership of, 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 for week one. We spent two days on a landing page in week 1. Wasted. By week 3 we had cut and rewritten 80% of it because we did not yet understand who was buying. Build the product, then build the page once you have shown it to real people.

The takeaway

Solo engineers can ship more software than two-person teams could ten years ago. The tooling changed. The leverage is real. The bottleneck moved from "can we build it" to "do we know what to build."

If you have an idea and are still asking whether 45 days is realistic — it is. You just have to be honest about what you cut.

Want help building yours?

If something here resonated, we'd like to talk. 20-minute discovery call, no commitment.