Good fit when
- The product idea has too many possible first features.
- You need real user behavior before raising or spending more money.
- A no-code prototype proved interest but cannot support the next step.
- You need a working backend, not just a clickable mockup.
How we build it
- 1Find the riskiest assumption and the smallest proof loop.
- 2Cut version-two features before estimates are made.
- 3Build the core user flow with enough admin visibility to operate it.
- 4Launch to a small audience and use the evidence to decide what comes next.
Expected outcome
A real product slice that can create evidence in weeks, not a months-long build that only proves you can spend a budget.
An MVP is the smallest version of the loop that can be used for real
A useful first version is not a cheaper copy of the finished product. It is the shortest path through the thing that has to work — the sequence a user repeats to get the value you promised — built well enough that real people can use it without being coached through it.
Writing that loop as a single sentence is the first deliverable, and it is where most scope arguments get settled. Mincha Time's loop was: know where the user is, calculate today's window, remind them before it closes. Everything else a prayer-time app could be — a full siddur, a calendar, community features, a settings-heavy utility — was left out on purpose. That decision is why the first version took about a month.
Mincha Time: what one month bought
The visible half is a landing page with multilingual messaging and a phone-style preview of the two reminder moments. The other half is a scheduled notification engine that has to fire the right message, in the right language, at the right minute, every day, for every location, built on Firebase Cloud Functions, Firestore and Firebase Cloud Messaging, with zmanim from the Hebcal API.
Six languages — Hebrew, English, Russian, Spanish, French and Yiddish — live in a plain translations map keyed by a per-user language field, with no i18n library. A monthly cleanup job removes tokens and records for users inactive more than thirty days. Neither is impressive engineering. Both are much cheaper to include on day one than to retrofit later.
Cheap architecture choices that still hold up
The schedule is data, not infrastructure
A function runs every minute and checks whether a Firestore document exists for the current time bucket, keyed hour_minute. No queue service, no per-user cron job, nothing extra to operate.
Call the expensive thing once
Users are grouped by rounded latitude and longitude, so the Hebcal API is called once per location per day rather than once per user.
Let each run schedule the next one
After today's send for a location, the same run fetches tomorrow's times and writes tomorrow's bucket. The system moves forward one day at a time instead of precomputing a calendar it might have to throw away.
Two independent ways to stop
A permanent disable and a same-day snooze, both checked before every send. For anything that sends messages, opt-outs are not a version-two feature.
Where the shortcuts are, and why they were still the right call
Being specific about the seams is part of the work. In Mincha Time the next day's time bucket needs a UTC offset, and that offset is parsed out of the Hebcal response string. It works, and it is the kind of manual parsing that would have to become a proper timezone library if Hebcal ever changed the response format. The per-minute run also fires whether or not anything is due, which is cheap at this scale and is the first thing that would change if the user base grew by an order of magnitude.
Both are written down in the case study rather than hidden. Knowing where a shortcut is means it can be replaced deliberately, when traffic or the roadmap calls for it, instead of being discovered during an outage.
How long an MVP takes, using builds you can go and look at
Three real durations, all shipped and live. Mincha Time, about one month: one calculation, one reminder, no payment step. Domino Ra'anana, about two months: a public menu, deals with their own options, cart and checkout, card payment through Cardcom, a cash path, customer and admin emails, admin screens and the Aviv POS handoff. Djob, about six months: a two-sided recruiting workspace with embeddings, gated matching, snapshot tables and admin flows on both sides.
None of those is a quote for your project, and none of them is a rate card. They are the shape of the answer. One integration and one user flow is a month-sized problem. Money plus an external system of record is a two-month-sized problem. Two audiences who need different things out of the same data is a six-month-sized problem. If an estimate you are reading sits far off that scale, the useful question is what it contains that Domino's checkout did not.
What launch day is actually for
The point of shipping early is evidence: which step people abandon, which message they ignore, which feature nobody opens. That is why a first build includes enough admin visibility to operate it — you cannot learn from a product you cannot watch. The list of what to build next comes out of that, and it is usually shorter, and different, from the list you started with.
Worked example: a first version that had to run unattended
Mincha Time could not be a clickable prototype, because the whole promise happens when the user is not looking at the app. That constraint decided the scope of the first month.
- 1Decide what the product refuses to beNot a siddur, not a calendar, not a community platform. One daily outcome: help somebody know when mincha is relevant where they are, and remind them before it passes.
- 2Build the loop, including the unattended halfLocation, zmanim from Hebcal, and a minute-resolution scheduled send covering both location-group reminders and personal reminder times.
- 3Add only the operational necessitiesTwo opt-outs, six languages as lookup objects, and a monthly cleanup for users inactive more than thirty days.
- 4Write the known tradeoffs downThe offset parsing and the always-on per-minute check are recorded as the first things to revisit, so growth does not turn them into surprises.
A live product doing one job reliably, delivered in about a month, with the next round of work already identified rather than guessed at.
Questions we get asked about this
We already have a no-code prototype. Is that enough?
It is often enough to prove people are interested, and not enough to run a business on. Mincha Time and the Domino site both use Base44 alongside their own React front ends, and Mincha adds Firebase Cloud Functions for the scheduled work. The line to watch is whether the next thing you need is a screen or a process that runs when nobody is looking. Prototypes are good at screens.
Does an MVP get thrown away once it works?
Not necessarily, and it is worth building as though it will not be. The Domino ordering site has been in daily use for more than five years, and the direct connection to the register was added later, after the site had proven itself. A first version that was scoped tightly and written clearly is usually the cheapest thing to extend.
What if the MVP shows the idea does not work?
Then it did its job at the cheapest point in the project, and it usually points at the nearby problem that is the real one. Finding that out at the scale of a one-month build is the entire reason for keeping the scope tight.
Typical deliverables
- Core user flow map
- Clickable product plus working backend
- Authentication and basic admin views
- Deployment and launch checklist
Best for
Founders and operators who need a working product, not months of planning documents.
Discuss this service