From Designing Houses to Debugging Code
I spent years as an architect, designing homes for people — thinking about how light falls in a room, how a hallway makes you feel when you walk through it.
Today I’m a self-taught SaaS founder with zero coding background. Here’s how that happened — and a question I’d love this community’s take on.
The problem I couldn’t unsee
After architecture, I started creating digital products for designers and architects — templates, guides, small tools to make their work easier. To sell them, I did what everyone does: I ran ads.
And I watched the same thing happen, over and over. Visitors would land on the sales page, read everything, hover over the price… and leave. Not because the offer was bad. Because of one small moment of doubt nobody was there to answer.
So I did what most of us do — I spent more on ads to “fix” it. More traffic, same leak. It took me a while to realize the problem was never traffic. It was the silence at the exact moment someone almost said yes.
So I built the thing I wished existed
I taught myself Lovable, wired up Supabase for the backend, and used Claude’s API to build FlowEra — an AI that detects that exact hesitation moment on a sales page (price hover, exit intent, scrolling to the bottom) and starts a warm, real conversation right then, in the creator’s own voice, to bring the visitor back.
No dev team, no co-founder, no CTO. Just me, a lot of trial and error, and a problem I’d watched too many creators — including myself — quietly lose money to.
Where I am right now
A recent Reel about this got close to 14,000 views, and a free quiz I built to show creators their own leak point has been quietly building a list of warm, engaged leads.
Right now I’m figuring out the best way to turn that warm interest into paying customers — especially without a short free trial. For this kind of tool, a few days just isn’t enough time to actually see results, so a trial would set people up to cancel before the product even proves itself. I’m leaning on other ways to build trust instead.
None of this is really about hitting a number for me. What actually excites me is knowing that somewhere, a creator is spending less on ads this month — not because they cut their budget, but because the leads they already paid for stopped quietly slipping away. That’s the entire reason I built this in the first place.
the architect background isnt a footnote here, its the actual skill. a hallway works because it answers "where next" exactly when you ask — not with a sign at the front door. your page leaks because the answer to that doubt already exists, its just not AT the price, where the doubt actually happens. so id not stack more proof up top — id move the one objection-killer down to the exact moment someone hovers and hesitates.
The line about silence right when someone almost says yes is sharp. A lot of founders respond to that by chasing more traffic, when the better move is usually to pin down the exact objection and build around it. I learned that the same way building DictaFlow, the most useful copy came from the oddly specific sentences users sent when something almost worked for them. If you keep hearing the same hesitation, I'd turn each one into onboarding, proof, or a small product fix before spending more on clicks.
This trust-without-a-trial problem is so real, we've hit the same wall with hiring products, you can't prove that kind of outcome in a few days. What's worked for us is leaning on specific outcomes from similar customers instead of just trial access, and maybe a hands-on pilot with a few warm leads so they actually see the leak close before committing.
What stood out to me is that you're not trying to increase conversions—you’re trying to intervene at the moment uncertainty appears.
That's a subtle but important distinction. If you consistently solve hesitation instead of simply adding another chat widget, you're defining the product around a decision rather than a feature.