Although we have always quoted 1-1.5 months for a SaaS build, we most often get ~80% of it done in the first week or two. Things that hold us back are more around getting access from vendors, API access, reviews and revisions from the clients rather than coding.

And now with Claude Code and Codex, this is the case for all of the builds.

This strongly moves where the founders need to pay attention and money…

(Spoiler: marketing and sales)

Our best clients were already making money and serving customers through n8n, Make, vibe-coded apps before moving to a full custom build. We want to lay out how you can do the same.

What you’ll learn

You will learn how to take a B2B software idea to its first customers, in the FASTEST way humanly possible as of late 2026 without worrying about the code, while aiming for revenue and usability rather than “code”.

By the end of this, you will

1. Sell an outcome to a company 10,000x your size without a product, a demo, or a single line of code
2. Put sales and distribution first
3. Understand and know how to verify data access, vendors, competition, permissions, etc
4. Replace your first engineering hire with n8n and a $100/mo Claude plan AND fulfil a five-figure contract in 2 weeks
5. Use those deployments to decide what platform to build and how

💡 Note, for some of our flagship clients, we actively run major parts of early stage growth as well. This article is a summary of our learnings from those early experiments.

1/ NEVER EVER SELL THE SaaS. SELL ONLY THE OUTCOME

Do not PITCH the SaaS. “Acme is a SaaS platfor….” NO. There’s no platform. There’s no AI. There’s no system. There just is “we help ICP with OUTCOME”

Start with what the buyer wants done. Cut response time by 50%, increase volume of production by 2x, get 100x more… If you say “I have an AI platform to generate videos”, you will be laughed out of the room.

But if you say “I can help your organization streamline and massively speedup video production pipelines, cutting time to a full published video in 1/2, etc” - then its of value to the business owners.

You sell and charge for the value you deliver, not for what you build.

For example, when we were building Prescriptive Intelligence, we talked to over 20 companies and code was NEVER the topic of discussion. Not in a single conversation it was bought up. Why? Because the conversation is never about what we built, its always about what they want. The core tenants of any SaaS offering are simple, but working and understanding a business deeply and building an solution for it is where the real $$ is.

Some things have to change for you to sell an outcome

• You take most of the risk - if you cannot deliver the outcome, you don’t get paid.
• You need to be able to be articulate and deliver a clear delta in value to the business
• Dont waste your time on taste or looks. B2B businesses don't care about your DEsIgN, they care about usability. There are million dollar businesses being run on Windows XP.

We have already written a deep article on what Outcome as a SaaS is and what it looks like in practice. Check it out here.

2/ Sales, Distribution & Growth above ANYTHING and EVERYTHING

Back in 2022, pre-ChatGPT days, even convincing B2B enterprises you had a SaaS was substantial work. Show them the wireframes, mockups, meet with their teams, some even asked to share the resume of your team members.

Users believed that building a SaaS is incredibly difficult. This is no longer the case.

Now no one doubts if you can build a SaaS. Its the business applicability that people grill you on.

You can put a WORKING PROTOTYPE in front of them in the first week, get specific feedback, and change it immediately. We covered that process in How We Use AI to Speed Up UI/UX Design Phase. (THANK YOU DARIO AMODEI.)

So the 2 to 3 weeks that used to go into convincing people the software could exist now goes somewhere else. Sales and distribution. Here is what that looks like in practice, in the order we do it.

Step 1. Become the MOST INFORMED person in THAT room before you build anything.

1. Book demo calls with every competitor. Go in as a buyer. You will get their pricing, their onboarding process, which APIs and platforms they integrate with, and their case studies, for free.
2. Write down what your buyer already pays for, how they use it, and where it breaks. If you cannot name the 3 tools they log into every morning, you are not ready to sell to them.
3. Find out who funded the competitor's last round and what the round was for. That tells you what the market believes the hard part is.
4. Go to the point of obsession. Down to what they eat for breakfast. This research is the most valuable thing you will do in the first month, and it costs nothing.

Step 2. Build the assets that get you in the room. All of them, before the first call.

• Website
• Landing page for the one outcome you are selling
• Sales deck
• Lead magnet
• 5 to 10 blogs on the buyer's problem, not on your product
• UI wireframes
• Technical architecture diagram
• A Lovable demo you can click through on a call

Nobody on the buyer's side reads the architecture diagram. It exists because the one person who asks for it is the one who kills the deal if it isn't there.

Step 3. Start outbound the same week the website goes live.

Not after the demo is polished. Not after the deck is final. The week the site is up.

For the RFQ system this was: website live, cold calling campaign started, both in the same week. One persona, one outcome, one message: sales leads at manufacturing companies were losing days responding to RFQs with quotes, and we help with that.

Pick one channel and run it hard before adding a second. Cold calling, partners who already sell to your buyer, creators your buyer listens to, ads, SEO, pamphlets. Whatever reaches them.

Step 4. On the call, do NOT start DEMO. Discover First.

• Ask what they are trying to get done and what happens at each step today.
• Ask which numbers they already watch and which problems already have someone's name on them. That is the outcome you sell.
• Show the Lovable prototype only to make their questions more specific. They will point at a screen and tell you what would actually happen in their business. That is the requirement.

Step 5. Keep the growth + engineering team at 2 or 3 people until client 10.

This whole motion, research, assets, outbound, calls, delivery, is 2 or 3 people. If you need something technical you cannot do yourself, get it from Fiverr. Nobody joins full-time before you have 10 to 15 paying clients. Before that, a technical team is baggage you pay for every month while you are still figuring out what you sell.

Which is possible because the tech you need for the first 10 clients is something you can build yourself.

And that brings me to the next point….

3/ Just Build the tech yourself (Claude will help ofc)

Rohan asked for this as its own section, but we will write a stand alone article on this!

For the first 10 clients the tech is a Lovable frontend the buyer sees on the call and an N8N backend that does the work. They never have to touch.

The demo: Lovable, one shot.

One-shot the entire dashboard in Lovable. It builds screens that look better than most shipped products, and when the real thing ships later it looks the same. That is your wireframe, your mockup and your clickable demo in 5-6 hours. Show it on the call to make the buyer's questions specific. Never wire it to real data before someone has paid.

The working system: N8N backend + Lovable Frontend

The pattern for almost every first deployment we have run:

1. Export from the client's system of record. Their CRM, their ERP, their dealer management system. A CSV is fine.
2. Your logic decides who to act on and when. n8n or Make for the flow, a script or Claude Code for anything the nodes can't do.
3. Act through an off-the-shelf tool. Email sequences, SMS, a call tool, whatever the channel is. You do not build the channel.
4. Hand the result to the client's humans to close.

A $100 Claude plan, an N8N instance, first client live in 2 weeks.

When you actually have to write code.

Rarely.

Internally we call the working system a jerry-rig. Do not say that to a client. The client-facing line is "we implement our process on top of your existing systems."

Now you know what you can build yourself.

4/ Business Feasibility Now Supersedes TECHNICAL Feasibility

See, tbh, the things I said above about building sales and distribution, are easier said then done.

Building a SaaS has become much more of an exercise in building a business. Someone has to arrange everything the code assumes will be there.

In these engagements, the initial application often moves quickly. Data access, vendor requirements, permissions, and the customer’s own processes take longer.

Manan, our business operator, works with clients to understand those processes and turn them into requirements. The discovery questions are straightforward: what happens at each step, what information is needed, who acts, and what happens outside the software?

Discovery questions mostly revolve around:

• Can we get the export, and does it contain the fields we need?
• Can the client grant access, or do we need their vendor?
• Which third party performs the core work? What does it charge, and what limits apply?
• Who already sells this result? What are their prices, terms, and implementation requirements?
• What consent and data handling requirements apply?
• Who handles missing information, failures, and exceptions?
• After tools, usage, human review, setup, and support, does the offer make money?

Only when after all this is done, technical feasibility becomes a valid question to ask. You will know from calls what things you can just have lovable build and what things claude code can crank out in 2-3 days of building. It is very rare where you need to solve something novel.

Most of the tech is solved, you just need to apply and use it in a certain order to reach to an viable software.

5/ Someone said YES, now what?

When a Fortune 500 buyer says "okay, we want to use it," you need a tech system, immediately. You do not need to connect that system to the app they saw on the call.

Every AI product is a layer on a system of record. The CRM, the ERP, the ticketing tool, whatever the client already runs. Their data already lives somewhere you can export from, so there is no integration project between you and the first result.

Building the tech does not matter. Getting to the outcome does. Nobody is going to ask how you got there.

Wrap Existing Tools

Export from their system of record, filter with your own logic, act through an off-the-shelf channel tool, route replies to their team. No integration project. Most first deployments look like this.

You can just use APIs for everything. Throw Opus at the problem. Whatever it takes in the early stages. Paying for API calls on a paying client costs you a fraction of what building your own tech with zero users would, and you can rip it out later once you know what the volume looks like.

We recently ran a solution offering around accelerating RFQ responses for sales leads at manufacturing companies. Quotes used to take over 2 weeks, in some cases months, and by then someone else had fulfilled the order. We pulled as much information about the space as we could, a lot of it from competitors, and once we had that level of sophistication we started cold calling. Every cold call taught us something about the company, every video call taught us more, and people kept bringing up their own niche problems. With enough of those calls behind us we were able to build a base version internally that covered about 70% of what any company in the space would need. Then on every call, from what we had already gathered about that company, we made that same base specific to them, which pushed it to 90 to 95%.

Build a Narrow App ONLY for One Client

Sometimes no existing tool does the thing, not even partially. Or the client really requires something niche. In our case, this was the identification of what operations are required to manufacture an machine part. No API gave us that. Thats when you build the tech.

But you build for that one client: their users, their systems, their workflow, nothing else. Skip scalability, multi-tenancy, billing, admin panels, onboarding. Do not skip reliability, access controls or data handling. B2B really needs that.

After 3 to 5 pilots have stress-tested the system: a setup fee, a monthly subscription, and a performance component where it fits.

Performance pricing works when the unit is measurable and your system takes ownership of what produces it. It does not work when the outcome depends on their salesperson, lands 6 months later, or carries no risk. In such cases, price on the nearest leading indicator and put the outcome in a kicker.

Clone the base. Adapt per client.

Each deployment tells you what repeats and what was specific to client 1. By client 5 you know what delivery actually costs. By client 10 you know whether you have a product.

ANDDD That's How You Sell Software That Doesn't Even EXIST Yet

Sell the outcome, never the platform.

Put the research, the assets and the outbound ahead of any code. Build the tech yourself on N8N and a $100 Claude plan.

No funding round. No engineering team. No code until someone has paid for it.

If you're looking to work with a company that has already done this and supported multiple clients through this exact process, work with us.