You’ve got an idea. A real one. Maybe a SaaS product that solves a problem you’ve seen repeatedly. Maybe an AI agent that could automate something your industry does manually. Maybe a web platform that needs to exist yesterday.
The usual advice tells you to spend 6-12 months building in secret, perfecting every detail, raising money, hiring a team. Then you launch to crickets because the market moved on, your assumptions were wrong, and you’ve burnt time and capital on features nobody wanted.
We ship MVPs live in 28 days. Not “almost ready” or “will be ready soon”. Live. Real users. Real feedback. Real revenue sometimes.
Why 28 Days Matters
Speed isn’t about rushing. It’s about forcing clarity.
When you have four weeks to ship, you can’t build everything. You can’t build anything that isn’t essential. That constraint is a feature, not a limitation. It forces you to answer the hard questions early:
- What is the actual problem you’re solving?
- Who will pay for it, and how much?
- What’s the minimum thing that proves the problem exists?
- Can you build it without custom infrastructure, fancy DevOps, or architectural gold-plating?
Most failed startups didn’t fail because their MVP was too simple. They failed because they spent a year building the wrong thing.
A 28-day cycle also means you can iterate with real data every month. Not every quarter. Every month. That’s 12 learning cycles a year instead of 4. Compounding that speed difference is how you outpace competitors who are still in month 3 of their “build”.
The Architecture That Actually Ships
Here’s where most founders go wrong: they design the system for scale before they have customers. They obsess over database architecture, microservices, caching layers, and deployment pipelines when they need to obsess over making something people want.
For a 28-day ship, your tech stack should be boring and proven:
- Pick a framework with batteries included. React or Vue for the frontend. Next.js, Django, or Rails for the backend. Don’t use a framework that requires you to build authentication, ORM, or routing from scratch. You’ll lose two weeks to infrastructure.
- Use a managed database. PostgreSQL on AWS RDS or Render. Not self-hosted. Not hand-rolled. You’re not spending time tuning query performance; you’re shipping features.
- Host simply. Vercel, Render, or Railway. One-click deployments. Automatic scaling up to the point where you have actual scale problems (which is a good problem to have).
- Use third-party services for everything non-core. Stripe for payments. SendGrid or Resend for email. Auth0 or Clerk for authentication. Cloudinary for images. You’re not writing file upload handlers; you’re building your product.
- Skip the AI infrastructure theatre (unless AI is your core).strong> If you need GPT-4 or Claude, call the API. Don’t fine-tune models, don’t build custom inference pipelines. Buy the capability and move forward.
The system you build in 28 days will be monolithic. Possibly a single codebase. That’s fine. You can refactor and scale later when you’ve proven people want what you’re building. Premature optimisation has killed more products than poor performance ever has.
What You Actually Build (and What You Don’t)
The ruthlessness required to ship in four weeks comes down to this: every feature must pass a test. “Does this prove we’re solving a real problem for people who will pay for it?”
What makes the cut:
- Core workflows that directly solve the stated problem
- User authentication and basic account management
- One payment integration (usually Stripe)
- Enough reporting or data visibility so users understand what’s happening
- A way for users to contact you (email, Slack, a form-pick one)
What doesn’t:
- Admin dashboards and internal tools (build them as you hire)
- Advanced analytics or BI features (basic metrics only)
- Mobile apps (web works on phones; ship that first)
- API documentation for third-party integrations
- Anything described as “nice to have”
Your 28-day product will have rough edges. The onboarding might be manual. The data export might be a CSV download. The documentation might be a Loom video and a Google Doc. Ship it anyway. Rough edges and manual processes don’t stop people from paying if the core value is real.
The Team and Process
You cannot ship an MVP in 28 days with a large team, a long approval process, or meetings about meetings. You need:
- A product person or founder who can make decisions. Not a committee. One person who knows what the MVP is, can say no to scope creep, and can decide in under an hour whether a feature makes the cut.
- A backend engineer. Ideally full-stack, but at minimum someone who can build APIs, set up databases, and understand data flow.
- A frontend engineer or designer. The UI doesn’t need to be beautiful, but it needs to be usable. Confusing products are slower products.
- Optionally, an AI specialist (if your MVP is AI-heavy).strong> Someone who understands prompt engineering, API costs, and output reliability. Not a researcher. A builder.
That’s three to four people, max. Everyone works on the same backlog. Daily standups, not hour-long planning sessions. Asynchronous communication where possible (Slack, not meetings). Merge code to production daily (or at minimum every 2-3 days). Testing is automated or skipped for the MVP (yes, really-test in production with a small set of real users).
Launch, Gather Data, Iterate
Day 28 arrives. Your product is live. It’s not finished. It might not be polished. But real people can use it, and you can measure whether they actually do.
Here’s what happens next:
- Push it to your network, angel investors, and warm leads in your target market. Not a big media launch. Targeted, personal outreach.
- Watch the metrics. How many people sign up? How many come back? Where do they drop off? Which features do they use?
- Talk to every user in the first month. Not a survey-actual conversations. Why did they sign up? What’s confusing? What would make them recommend it?
- Build features or fix things based on what you learned. You have four more weeks before the next “ship”.
Most founders are terrified to put an unfinished product in front of people. That instinct is usually wrong. People are more forgiving of rough MVPs than you think. They care about whether you’re solving their problem, not whether the button is perfectly rounded. And the feedback you get from a real MVP is worth more than a thousand hours of theoretical design.
If you’re ready to move from idea to shipping in 28 days, talk to Amora about your build. We work with founders and operators who want to test an idea, validate a market, or ship a product before their competitors wake up. We know what ships fast and what doesn’t.
The Real Trade-Off
Shipping fast means you’ll have to rebuild things later. You’ll refactor code. You’ll redesign the UI based on how real users actually behave. You might throw away work. That’s not a failure; that’s the cost of not wasting six months building the wrong thing.
The founders who get this-who understand that the first version is a learning machine, not a finished product-are the ones who succeed. They ship. They learn. They iterate. They ship again.
Four weeks. Real code. Real users. Real feedback.
That’s how you move fast enough to actually move markets.
Got something you want built?
Amora Digital is an Australian software and AI agency. We scope it, build it, and ship it – live in 28 days. No offshore teams. No surprises.