- What should the first version actually contain?
- One entity, one workflow, and one way in. If the idea is scheduling for tutors, the first build is a tutor with availability and a way to book -- not accounts, not payments, not a settings page. The question you are answering is whether anybody books, and every feature that does not move that answer is a week spent building confidence rather than evidence. You can add the rest in an afternoon once somebody has asked for it.
- Should I start with a landing page or the product?
- Start with whichever one you would be willing to change your mind about. A page with a clear promise and a signup box tests whether the problem lands, and it costs an evening; a working prototype tests whether your solution is any good, and only matters if the problem tested well. Founders who build the product first usually do so because the page feels like it is not real work, which is precisely why it is the cheaper experiment.
- Does it matter what I name things this early?
- More than it should. The words in your first schema propagate into routes, into the interface, into how your team talks, and into the migration you write in six months to rename them. If your users say job and you write task, you will translate between the two forever. Spend ten minutes on the nouns before the first build, and use whatever your customers already say rather than the abstraction that feels more general.
- What is safe to skip in an MVP and what is not?
- Skip settings, roles, onboarding tours, empty-state illustrations, and every integration nobody has requested. Do not skip a way to get your data out, a way for a user to reach a human, and a plan for deleting somebody who asks. Those three are cheap on day one and expensive to retrofit under pressure, and the first two are what make early users forgive the rough edges in everything else you skipped.
- Can I hand this to an engineer when I hire one?
- Yes, and it is worth knowing what they receive: a Vite and React front end, a Hono worker, a Drizzle schema, and migrations -- an ordinary TypeScript codebase they can run locally, read, and change. There is no proprietary runtime and no export step that degrades the code. The realistic conversation with a first engineer is about the decisions you made, not about escaping the tool you made them in.
- What breaks during a live investor demo?
- Empty databases and optimism. A product with three seeded records looks like a prototype, so populate it with realistic data and a story that runs through it. Open the app before you present rather than during, have a screen recording ready for the network to fail on, and rehearse the exact click path -- the improvised detour into a screen you have not opened this month is where demos go quiet.
- When should I add authentication?
- When data becomes personal, and not before. A single shared prototype needs no accounts; the moment two people should see different things, you need them. The full-stack template ships hashed passwords, signed sessions with expiry and revocation, and lockout on repeated failures, so adding it later is a prompt rather than a project. Building accounts first is the most common way a founder spends week one on infrastructure nobody has used yet.
- How do I keep changing things without breaking what works?
- Change one surface at a time and keep schema changes separate from interface changes. If a build alters the database and redesigns a screen at once, a failure gives you two suspects. Describe changes as additions where you can -- a new column with a default is safer than a rename -- and keep a copy of anything real before a migration runs. Momentum comes from small reversible steps, not from large ones you are afraid to undo.
- Can I test pricing before building billing?
- Yes, and you should. Put the price on the page, take the intent, and invoice the first handful of customers by hand -- a payment link and an email will carry you further than a subscription system. What you learn is whether the number causes hesitation, which no amount of billing code reveals. Automate collection when the manual version becomes annoying, because annoyance is the signal that you have enough customers to justify it.
- What does the free tier let me do before I pay?
- Enough to find out whether this works for you: an allowance you can build real things with, no card required, subject to both a daily and a monthly limit. Paid plans raise the allowance and add custom domains and faster support. The specific numbers change as models and costs change, so read them at fabricate.build/pricing rather than trusting a figure quoted in a comparison post from last year.