Skip to content
Codedock
ServicesHow we workInsightsCase StudiesCareerContact
Back to all articles
Architecture & Consulting

·

6 min read

·

Written by Tomáš Mikeš

SaaS in 2 months that doesn't collapse in six: what to cut, what not to

Fotopast.cloud went to production 60 days after kickoff. Not a marketing trick — a series of conscious decisions about what ships and what gets deferred. Here are the rules we use.

SaaSArchitectureDeliveryMVP

“Can you build our SaaS in 2 months?” Asked five times in the last year. The answer is: it depends. Fotopast.cloud hit production exactly 60 days from the first kickoff call and has been running without major rewrites for 18 months. Other projects we were asked to ship in 2 months would have ended as technical debt within 6 months post-launch.

The difference isn't team size or miracle AI tools. It's what you include in MVP and what you consciously defer. Five rules we use.

1. One auth flow, not five

Authentication is the largest “stealth” work in SaaS. Email/password + social login + SSO + magic link + MFA = 5 different flows × 5 screens × testing × edge cases. 2 weeks just on that.

For Fotopast MVP: only email/password + password reset. Social login (Google, Apple) and SSO went into phase 2. Reason — in the first version users come in via email printed on the trap cameras. They have email; maybe they have a Google account; they definitely don't have SSO.

2. Free plan with sensible limits, zero billing code

Stripe integration + subscription management + invoice generation + VAT handling + dunning = 3-4 weeks of work. In an MVP where you don't know which pricing will stick, that's burnt time.

Fotopast MVP: 1 GB storage free per user. Zero billing code, no Stripe. Only after 3 months of operation, once we saw actual usage patterns, did we add pricing.

Alternative: manual invoicing through a billing tool (e.g. Fakturoid) for the first 50 customers. Not elegant, but zero dev days. When the business confirms the pricing works, then automate.

3. Admin UI for 80% of cases, the rest through SQL

“We need an admin portal for everything.” Maybe, but not in MVP. Full CRUD for every entity = 4-6 weeks. In MVP the client (founder) needs to be able to:

  • Add/remove users (admin UI)
  • See the device list (admin UI, read-only)
  • Export data for reporting (admin UI)

What we did NOT put in admin UI: edit config, refunds, account cancellation, pricing updates. The founder has SQL access — in the first 3 months this happens 5× a month, not 50×. Saves 3 weeks of development.

Critical: log every SQL change from admin. One day someone deletes something important, the audit trail saves you.

4. No enterprise-grade multi-tenant isolation

Full data isolation per tenant (schema-per-tenant, encryption keys per tenant, audit logs per tenant) is 4-8 weeks of work and not needed until an enterprise customer demands it.

MVP: shared DB, shared tables, a tenant_id column on every row, proper indexes. Enough for the first 100 customers and everyone who isn't a bank or healthcare. When a customer explicitly wants data isolation, code changes run 1-2 weeks. If you pre-build that for MVP, it's 4-8 weeks wasted.

5. Monitoring from day 1, not “when there's time”

The one thing that doesn't get deferred: Application Insights / Sentry / some log aggregator from the first deployment. 1 day of setup. Pays back 10× in the first month when something misbehaves and you have no clue what.

Fotopast MVP: Application Insights plus a custom dashboard for key metrics (signups/day, photos uploaded/day, error rate). When uploads from one camera model started failing repeatedly in week 3 after launch, we knew before the client did.

What that means in numbers

If Fotopast had full auth + billing + admin UI + multi-tenant isolation + monitoring on day 1 — 5-6 months of work.

With pragmatic scope triage:

  • Auth (email/password only) — 3 days
  • Billing (manual via Fakturoid) — 0 days
  • Admin UI (minimal) — 5 days
  • Multi-tenant (tenant_id column) — 1 day
  • Monitoring (App Insights setup) — 1 day

= 10 days saved out of the 30-40 a full version takes. Plus a month of development time freed for core functionality — photo ingestion, PWA, device management. That's what the product exists for. Auth/billing/admin can come once the product proves itself.

What CAN'T be skipped even in 2 months

Five things that can't be deferred, even when it sounds tempting:

  • Automated tests on the core path, at least. Not 80% unit-test coverage, but integration tests for signup-upload-view-logout.
  • CI/CD pipeline. Manual deploys in a 2-month MVP = 2 days of work tainted in maintenance mode.
  • Database backups + a disaster recovery plan. Don't rely on “the cloud backs up” without a restore test.
  • HTTPS + security headers + OWASP basics. Zero cost, uncapped risk.
  • Basic privacy policy + GDPR flow (right-to-delete, data export). Cheap in MVP, expensive ex-post.

The underlying point

“Ship fast, refactor later” is a dangerous slogan. But “ship an MVP with consciously deferred pieces and a clear plan to add them” is a different story.

The difference is whether you know what you're deferring, and why. Fotopast.cloud in 2 months wasn't in conflict with “solid architecture.” It was a deliberate architecture of what fits in 60 days, with a documented phase-2 plan.

Working on something similar?

Book a 30-minute technical call. No sales process — direct architectural feedback.

Pick a time

Architecture, cloud and integration for complex systems. A senior architect on every project.

Navigation

ServicesHow we workInsightsCase StudiesCareerContactAgency vs. freelancer vs. us

Services

DevelopmentCloudDevOpsAI & DataConsultingDelivery

Contact

CodeDock s.r.o.

Zlenická 863/9, 104 00 Praha 22

Czech Republic

info@codedock.com

Company ID: 14292769

VAT ID: CZ14292769


© 2026 Codedock

ContactPrivacy Policy
Book a call