The first month of an AI B2B SaaS is usually spent building. It should be spent finding out whether building is warranted, and the difference compounds for a year.
What follows is a thirty-day shape. It assumes one or two founders, no funding pressure yet, and a domain you have some right to work in. It ends with either a signed design partner or a clear reason not to continue, and both endings are good ones.
What you’ll learn
- Week one: the artifacts, not the code
- Week two: twenty conversations that are not demos
- Week three: the smallest thing that could be wrong
- Week four: the ask, and what a real yes looks like
Week one — write the eight things down
Resist the pull toward a prototype for five working days.
Produce the artifacts instead: business model and position, product definition, market picture, brand, operating design, strategic dynamics, the venture canvas, and the synthesis of where they contradict each other. The point is not the documents. It is that answering the eight questions separately reveals which of your beliefs is load-bearing, and load-bearing beliefs are what you spend week two testing.
Two ways to do it. Run all eight straight through and read the synthesis, which suits founders who already hold the context and want the contradictions surfaced fast. Or work through them one at a time in a guided sequence, which suits the case where the thinking has not been done yet. Both are on starting a business.
The output that matters from week one is not an artifact at all. It is a list of the three or four assumptions that, if wrong, mean there is no business here. Everything after this is about those three or four.
Week two — twenty conversations
Twenty conversations with people in the segment. Not demos. Not pitches. Conversations about how the work currently gets done.
Two rules make the difference between twenty useful conversations and twenty polite ones.
Ask about last time, not about generally. "How do you usually handle X" produces a description of the process as people believe it works. "Walk me through the last time you did X" produces what actually happened, including the spreadsheet nobody mentions and the person who is the real bottleneck.
Do not describe your product. The moment you do, the conversation becomes a reaction to your framing and stops being data. Save it. If you cannot resist, save it for the last five minutes and treat everything said after that point as separate from what came before.
Twenty is the number because the shape of the problem usually stabilises somewhere between twelve and eighteen, and you want a few past stabilisation to know you got there. Ten design partners before a landing page covers what to do with the ones who lean in.
Important: If four conversations in you already know what everyone will say, you are not learning, you are confirming. Change the question, not the sample.
Week three — build the smallest thing that could be wrong
Now build. But build the thing that would be falsified fastest, not the thing that would be most impressive.
For an AI product this usually means the narrowest end-to-end path: one input shape, one output shape, real data from one prospective partner, no interface worth the name. The question the build has to answer is whether the output is good enough to change what someone does, on their data, in their vocabulary.
Three failure modes to avoid in this week.
Week four — the ask
The ask is not for money and it is not for a pilot. It is for a working relationship with a defined shape, and the shape is what makes it real.
A design partner agreement worth having states four things: what they get, what you get, how long, and how it ends. What they get is influence over the roadmap and early access. What you get is access to their real work, their data under a defined scope, and their time on a regular cadence. How long is a fixed window — six to twelve weeks is the usual range. How it ends is stated plainly, so that not continuing is a normal outcome rather than a failure.
A real yes has three markers. A named person with a calendar commitment, not a company expressing interest. Access to actual data or actual workflow, not a sandbox. And a stated definition of what would make it a success for them, in their words, which becomes your acceptance criteria.
Anything short of all three is a warm conversation. Warm conversations are pleasant and are not evidence.
What thirty days should have produced
At the end, you are holding one of two things.
Either a design partner with a defined engagement and a written definition of success, plus a list of the assumptions that survived contact and the ones that did not. Or a clear account of why the segment does not have the problem you thought it had, delivered cheaply, in a month, before you built anything.
The second outcome is worth as much as the first, and treating it that way is the difference between a founder who tests ideas and one who defends them.
If you want the structured version of the whole path, starting a business runs the eight tools and the synthesis, and design partners is how we run this on our own side. Start with an idea, or with the company you already have — the thirty days look much the same.
Brainis Team
Notes on the company loop — company state, decisions, governed autonomy and verified work — from the people building Brainis and running on it.