"Can you build our MVP in a month?" is a question I get often. The honest answer is: sometimes yes, sometimes no — and the difference is almost entirely in how you define MVP and how you make decisions.
This post is a transparent look at how Makhloof Studio approaches a 30-day SaaS MVP: what we do, what we deliberately skip, and what the output actually looks like.
First, what "MVP" means at Makhloof Studio
MVP is overloaded to the point of meaninglessness. Some founders mean "the first version with every feature." Some mean "a landing page with a waitlist." At Makhloof Studio, an MVP is:
A working product that real users can use to accomplish the core job-to-be-done, deployed in production, with the business logic correct.
"Business logic correct" is non-negotiable. If your SaaS handles money, subscriptions, or data belonging to multiple tenants, getting those parts wrong isn't a prototype tradeoff — it's a liability. We don't ship MVPs that get the important parts wrong.
What we do skip: polish, edge cases, advanced reporting, admin tooling beyond the minimum, and anything that isn't directly on the critical path of a real user completing the core workflow.
The 30-day breakdown
Week 1: Discovery and architecture (Days 1–7)
The first week is not coding. It's alignment.
Day 1–2: Discovery call and written brief. We discuss the product: who uses it, what they're trying to do, what success looks like at 3 months, what we're deliberately not building yet. I write this up as a brief and you review it. Ambiguity killed at day 1 saves weeks later.
Day 3–4: Data model and API contract. The data model is the foundation. Get it wrong and you're refactoring under pressure in week 3. I design the schema, walk you through it, and we agree on the entities and relationships before any code exists.
Day 5–7: Architecture decisions. Which hosting tier? What's the authentication strategy? How does billing work? Which third-party integrations are in scope for V1? These decisions get made explicitly, not implicitly by whoever writes the first file.
Output: A written document. A schema diagram. An agreed scope. No code yet — and that's intentional.
Week 2: Core backend and auth (Days 8–14)
Week 2 is the unglamorous work that makes week 3 possible.
- Database setup with migrations
- Authentication (email/password + magic link, depending on the product)
- Tenant isolation if multi-tenant (Row-Level Security in Postgres)
- Core business logic: the models, services, and domain logic that represent the actual product
- Billing integration (Stripe subscriptions or one-time payments)
- Basic API endpoints for the frontend to consume
You'll see working API endpoints by end of week 2, but no UI yet. That's correct.
Week 3: Frontend and integration (Days 15–21)
Week 3 is where it starts looking like a product.
- Authentication flows (login, signup, onboarding)
- Core product screens — the ones that let a user accomplish the primary job-to-be-done
- Wiring the frontend to the backend
- Basic error handling and loading states
- A minimal admin view if operationally necessary
I share a live preview URL at end of week 2 so you can start providing feedback early. Feedback loops in week 3 are critical — changes are cheap now; they're expensive in week 4.
Week 4: Polish, testing, and launch (Days 22–30)
- Addressing feedback from week 3 testing
- Email flows (welcome email, password reset, key transactional emails)
- Basic SEO setup for web products
- Performance pass — no premature optimization, but no obvious regressions either
- Deployment to production infrastructure
- Handover documentation: how to deploy, how to manage the system, what's in scope for V2
By day 30, the product is in production. Real users can use it. The important business logic is correct.
What makes this possible
Decisions made once, not revisited
Every hour spent relitigating an architectural decision in week 3 is an hour not spent building. The discovery and architecture week exists to make decisions once, in writing, before they're expensive to change.
No junior handoffs
On a 30-day build, there's no time for the overhead of code reviews that catch fundamental misunderstandings, or onboarding a junior to the codebase mid-project. At Makhloof Studio, the engineer who scopes the project builds the project. Senior judgment on every line isn't an aspiration — it's the model.
Modern tooling and AI leverage
I use modern tooling and AI assistance for the right tasks: boilerplate generation, documentation, test scaffolding, and code review assistance. This isn't AI replacing engineering judgment — it's AI compressing the tasks that don't require it so more time is available for the tasks that do.
Scope discipline
The hardest part of a 30-day MVP is saying no. Not to good ideas — to ideas that aren't on the critical path for V1. Every feature that gets added to the MVP scope takes time away from making the core features correct. A focused MVP that does one thing well beats a feature-rich product that does five things poorly.
What a 30-day MVP is not
It's not a prototype. It's deployed in production with real infrastructure.
It's not throwaway code. The architecture is designed to be extended, not replaced.
It's not feature-complete. That's the point. It's the minimum that lets you validate whether real users will pay for the thing you've built.
It's not the end. It's the beginning of the product lifecycle. V2 planning starts during week 4, while V1 is being finalized.
If you're evaluating whether a 30-day MVP is the right scope for your product, let's talk. I'll tell you honestly whether it's achievable and what tradeoffs it requires — before you commit to anything.