---
title: "Selling the workflow before the software"
description: "I delivered Luminik manually before building the product surface. That work showed which event workflows repeated and which steps belonged in software."
canonical: https://prasad.tech/blog/selling-before-building.html
source: html
generated_at: 2026-05-26T13:56:27.812Z
---
[Home](/) / [Blog](/blog/) / Founder-led sales 

 Feb 2026  10 min read Founder-led sales 

# Selling the workflow before the software

I delivered Luminik manually before building the product surface. That work showed which event workflows repeated and which steps belonged in software.

In Luminik’s early months I did not lead with a product walkthrough. I sent a narrow outbound message to a marketing leader whose team cared deeply about events, then offered to do the work for them. The work became real before the software did.

The argument in one paragraph 

If you can sell a manual version of the outcome, you learn faster than any prototype can teach you. The repeated parts of the work become the product. The non-repeated parts stay with humans. Build that boundary first, then write the code.

## Why I did it this way

At Mainteny I took the conventional path: built the first product, helped make the seed story concrete with a live product and customer evidence, then kept learning what the market wanted. Funding leaves the hardest company questions unanswered: who will buy, which channel opens the door, what language the buyer uses, where urgency comes from, and which part of the workflow is expensive enough to fix. With SnowOptix I approached investors too early and felt the cost of the same mistake.

I now try to find pull before I build too much. A buyer with pull has a project on their desk, a reason it matters now, a few options they have already tried, and a clear reason those options are not enough. That is a better signal than a compliment on the idea.

|                     | Build first, sell later (Mainteny)      | Sell the workflow, build later (Luminik)                  |
| ------------------- | --------------------------------------- | --------------------------------------------------------- |
| First artifact      | Product demo and pitch deck             | Outbound message and a calendar invite                    |
| First evidence      | After product fit                       | Manual delivery, while the product was still notes        |
| What you learn      | What people will demo                   | What people will pay you to handle                        |
| Cost of being wrong | Months of build time on the wrong shape | A few weeks of customer work that still produced learning |
| What ends up funded | Capacity to build                       | Confidence in what to build                               |

Two startup paths I have lived through. Both can work. The selling-first path needs less imagination.

## The first useful sentence came from the buyer

I had been thinking about automation. The buyer kept returning to the same idea: every event had its own quirks, and the real value was handling the messy middle well.

> Different events, different attendee sources, different platforms, different reps, different follow-up rules. The real need is someone accountable for the messy middle.

The first marketing leader I sold to, paraphrased

That sentence reshaped the company. I stopped trying to sound like a software vendor and started listening for the work.

## The manual loop that became Luminik

The first events were real, time-bound, and operationally messy. I had no software surface yet. I had the customer’s existing tools, a spreadsheet, and a lot of manual effort. From the buyer’s point of view, I was removing work without asking them to change how they already operated.

The five-stage loop, found by doing the work

1**Source**Find the event universe from lists, portals, speaker pages, and public fragments.

2**Enrich**Use the customer’s existing tools to fill company, role, and contact context.

3**Sequence**Write outreach around why this event matters to this buyer now.

4**Capture**Keep meeting notes, booth conversations, and AE context attached to the right record.

5**Attribute**Report what happened in a way sales and marketing could both use.

I did not invent these stages in a positioning exercise. I found them by doing the work manually until the repeated shape was obvious.

## What being embedded taught me

Several events overlapped and the work had to coordinate across sales stakeholders at the same time. It was too much for one person to keep doing manually, which was exactly the point.

|                                         | Repeats across events | Stays with humans               |
| --------------------------------------- | --------------------- | ------------------------------- |
| Data movement between tools             | Yes, automate         |                                 |
| ICP matching from event lists           | Yes, automate         |                                 |
| First-draft outreach per event          | Yes, automate         |                                 |
| Pipeline and attribution reporting      | Yes, automate         |                                 |
| Which accounts matter this quarter      |                       | Stays with the GTM team         |
| Which booth conversations to push       |                       | Stays with AEs                  |
| How aggressive the outreach should feel |                       | Stays with marketing leadership |

What the first months of manual delivery showed me about where software belongs.

Automate the repetitive parts. Keep account choice, tone, and escalation with the GTM team. That distinction became the product boundary.

## From manual delivery to product boundary

After the first delivery cycles, the work had stopped being speculative. The customer had seen me operate across real events, inside their real tools, with their real team. The value was a working model for an event motion that had been depending on too much coordination.

**Manual** First delivery 

No product surface until enough hands-on work had named the workflow.

**5** Stages, found by doing 

Source, enrich, sequence, capture, attribute. Stable across events.

**1** Buyer sentence 

Handle the messy middle. The line that reshaped what Luminik would be.

## When software finally made sense

I wrote the first code after enough delivery to know which parts deserved software. If I had built first, I would have designed from imagination. I would have overbuilt the clean parts and underbuilt the annoying parts. The annoying parts are usually where products live.

Luminik is still being built from that posture. Backend automation came first because it reduced delivery load immediately. The customer-facing UI follows the same rule: build the surfaces that make the workflow clearer, faster, and easier to trust.

The operating rule I use now

1. Find a buyer with a live operational problem.
2. Listen for the words they use when the workflow breaks.
3. Do the work manually inside their current process.
4. Notice which steps repeat across events, reps, and tools.
5. Ask for commitment once the manual work is clearly useful.
6. Write software around the repeated work.

## What I would tell a technical founder

If you can sell a manual version of the outcome, you learn faster than a prototype can teach you. You also learn which promises you are willing to be accountable for. That accountability keeps the product honest.

My bias now 

Sell the outcome manually until the repeated work becomes impossible to ignore. Then write the software around the repeated work. The boundary you find this way is harder to fake and harder to lose.

![Prasad Subrahmanya](/assets/images/header/prasad.jpeg) 

## Prasad Subrahmanya

Builder and operator at Luminik. Built Aura at Bain to $3.6M ARR, co-founded Mainteny through its $2.7M seed, and helped build the initial product and team.

[LinkedIn](https://linkedin.com/in/prasadus) [GitHub](https://github.com/prasadus92) 

[ Back to blog](/blog/) 

## Filed under

Founder-led sales Luminikfounder-led salesmanual delivery 

## Related notes

[**Technical founders sell through diagnosis**Technical founders sell well when discovery starts as diagnosis: understand the workflow, explain tradeoffs, and say what the product can and cannot do.](/blog/technical-founder-sales.html)[**Separating agent work from founder work**Why I moved recurring agent work out of my daily workspace, what the boundary controls, and which approvals still stay with me.](/blog/dedicated-mac-mini-solo-startup.html)[**SnowOptix: the side project that led to Luminik**SnowOptix started as a real Snowflake cost tool. The customer conversations mattered more than the tool and led me toward Luminik.](/blog/snowflake-cost-optimization.html)