What I Learned Launching My Own Software

I want to tell you something that surprised me about launching Maryn: the hardest part wasn’t the building.

I’d spent years in enterprise software — Product, Implementation, QA. I’d shipped financial software for big companies before I left corporate to be home with my kids. I kept my hand in with contract QA work on the side when they were little, but I never went back to a full-time corporate role. Even so — those years didn’t disappear. I knew how to write requirements. I knew how to run a release. I knew what good software looked like, what bad software looked like, and what the difference was at the architecture level.

And yet, when I sat down to build Maryn — software for myself and people like me — almost none of those instincts wanted to apply directly. Building software for one is a different sport than building software for fifty. The skills transferred. The mindset had to change.

I want to share what I actually learned, in case you’re another woman with a deep professional background sitting on an idea you keep telling yourself isn’t “the right time” for.

The product was years in the making, even if the build wasn’t

When people see Maryn now, they see a product. What they don’t see is the years of running my own creative business while working in enterprise software, watching every tool I used fail solopreneurs in some specific, grinding way. I’d been making notes — sometimes mental, sometimes literal — about what was missing for years.

By the time I actually sat down to build Maryn, the spec was practically written. I knew exactly which features mattered and which were noise. I knew what the daily-use loop should feel like. I knew what to leave out, which is harder than knowing what to put in.

This is the thing about indie software that doesn’t get talked about enough: the build phase is the small, visible tip of an iceberg of years of attention. People who try to launch in six weeks without that prior thinking either ship something half-baked or get stuck halfway. People who’ve been quietly paying attention for years can move fast when they finally start, because the design work is already done.

If you’re sitting on an idea right now and feeling guilty for not launching yet — consider that you might be in the iceberg phase. That’s not procrastination. That’s the work.

I cut features ruthlessly — because I knew what enterprise bloat looks like

The first version of Maryn that I shipped did not have many of the features I’d originally imagined. No fancy charts. No automated reminders. No integrations with anything. No mobile app. (Still no mobile app. Maybe never.)

What it had: income, expenses, mileage, a calendar, a daily task list, a journal, and a single-screen “today” view that pulled it all together. About seven things, all done well.

This is where my enterprise background actually hurt before it helped. My first instinct was to build the comprehensive version — every feature a solopreneur could ever want, all the edge cases handled, every workflow accounted for. That’s how you build enterprise software. You build for every possible user.

But Maryn isn’t enterprise software. It’s for one person, doing fifteen things, with a brain that needs to see it all at once. The enterprise instinct toward feature completeness is the exact wrong instinct for a tool like this. So I made a list of every feature I wanted Maryn to have. I crossed off two-thirds of it. I shipped what was left. The crossed-off list became my post-launch roadmap — and several of those features feel less urgent now that real people are using the simpler version.

Cut more than feels comfortable. Then cut a little more.

I priced it by how I wanted to feel about subscriptions

I’ve written about this before — Maryn is $197 once, no subscription. The decision was a values one before it was a business one.

I sat down and asked myself: how do I want my customers to feel about this purchase, in five years?

A monthly subscription means a customer who’s slightly resentful every month they get charged. They don’t open the app for two weeks, they see the $19.99 line item on their bank statement, and they feel a small sting. Multiply that across years and you’ve built a relationship of low-grade irritation.

A one-time purchase means a customer who feels like they own something. The relationship is settled. They open the app when they need it. There’s no resentment because there’s no recurring charge.

The math works out — not as well as a subscription would in the long run, but well enough. And it lets me sleep at night not thinking about churn rates. Pricing is a values decision before it’s a business decision. You can do the spreadsheet math after, but start with what you actually want.

I used boring technology on purpose

Maryn is built with Tauri. The whole app is essentially a single HTML file that opens in a desktop wrapper. Nothing in the stack is novel or experimental. I’m not running my own servers. I’m not writing a custom database engine. I’m not learning Rust on weekends.

This was a deliberate choice, and it’s the kind of choice you make easier when you’ve watched a lot of software not age well. Every “interesting” technical decision is a thing that can break, a thing you have to maintain, a thing that becomes your problem at 11 PM on a Saturday. Boring technology — well-documented, widely-used, ten-years-old — is your friend. It might not be impressive in a tech blog post. It will, however, still be working in five years without you doing anything.

The same applies to my whole stack. Email is Cloudflare’s free email routing. Hosting is Cloudflare Pages, free tier. Payment processing is Payhip — they handle taxes, refunds, affiliate tracking, all of it. I don’t run any of my own infrastructure.

Less to break. Less to maintain. More time to actually build.

I shipped before it was perfect — but not before it was good

The version of Maryn that went on sale was, in my professional judgment, ready. Solid architecture, clean code, the core workflows worked properly, the edge cases I cared about were handled. It was not, however, perfect. There were minor visual things I wanted to polish. Features I knew I’d add in the next month or two. The voice on the sales page wasn’t quite where I wanted it.

The distinction matters. There’s a difference between “shipping something half-baked because you’re impatient” and “shipping something solid that isn’t yet final.” The first is what makes indie software feel sketchy. The second is just how real software works.

If anything, my QA background made this harder, not easier. I knew exactly how much polish was theoretically possible and felt every gap. But I also knew, from years of release cycles, that the gap between “good” and “perfect” is usually three months of work for two percent of the value. You ship at “good.” You polish on the schedule that real customer feedback dictates.

Within a week of launching, I had real customer feedback. Most of what I’d been worried about? Nobody noticed. The things people did want? Mostly things I hadn’t even considered.

The thing I’d tell other women with technical backgrounds

If you’re a woman with a deep technical or product background and you’ve been sitting on an idea — possibly for years — for a small piece of software you wish existed: you are uniquely positioned to actually build it well, and you should.

The tech industry doesn’t make a lot of room for the woman who knows what she’s doing, doesn’t want to build the next unicorn, has no interest in raising VC money, and just wants to make a quietly excellent thing for people like her. That gap is yours to fill. Your background isn’t overkill for indie software. It’s exactly what’s missing from most of it.

Ship the smallest version of the thing. Charge for it from day one. Listen to the real users. Iterate from there. The quality bar you’ve been holding yourself to your whole career is the quality bar your indie product can have too — but only if you actually launch it.

Whatever you’ve been quietly paying attention to for years — it’s probably more ready than you think.