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.
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 |
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.
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.
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 |
Automate the repetitive parts. Keep the human judgment visible. 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.
No product surface until enough hands-on work had named the workflow.
Source, enrich, sequence, capture, attribute. Stable across events.
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.
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.
