Background
Before I ever tried building anything of my own, I spent years as a software engineer designing systems that had to survive reality: changing requirements, imperfect data, flaky integrations, and the slow creep of “temporary” decisions becoming permanent. I worked across product and platform work - shipping features, untangling legacy, and trying to make complicated things boring and dependable. Outside of the day job, I ran a small homelab and self-hosted the tools I relied on. It started as curiosity and turned into a habit: if something mattered to me, I wanted to understand it, own it, and keep it working. That combination (building software professionally, and operating real systems personally) shaped how I think: reliability is a feature, incentives matter, and small details compound.
Why I Started
I didn’t wake up with a grand “founder” identity. I got tired of waiting for the perfect moment and the perfect plan. I kept seeing the same pattern: good people doing good work, but bleeding time and energy to friction—tooling that doesn’t quite fit, processes that collapse under stress, and advice that sounds great until you try it on a random Tuesday. I wanted more agency. Not in a dramatic way, more in a “let me prove this works” way. Building something small, useful, and honest felt like the antidote to endless planning and external validation. I’m drawn to the kind of work where you ship, learn, adjust, and keep going - especially when nobody is watching.
What I'm Working On
Right now I’m focused on building a practical toolset for people who do serious work without a big support structure: independents, small teams, and builders who have to juggle delivery, admin, and momentum. I’m intentionally optimizing for “keeps working” over “looks impressive”: clear workflows, good defaults, and low operational overhead. In parallel, I’m writing more - partly to document what I’m learning while it’s still messy, partly to connect with others building in the same uncertain middle. The goal isn’t to perform progress. It’s to keep showing up, ship the next version, and make the work a little more sustainable each iteration.
IndieHQ (working codename for now - the “real” name will reveal itself once the project is much farther forward)
Building a practical, low-drama toolkit that helps independent builders run their work more smoothly - less admin friction, clearer workflows, and systems that keep working.
SaaS / Productivity tooling (solo founders, independents, small teams)
Visit WebsiteBiggest Struggle
Time, mostly. I’m building around a full-time schedule, and when you’re solo, everything is “the product”: coding, UX decisions, copy, ops, support, distribution, and the constant context switching between them. The hardest part isn’t any one task; it’s protecting enough uninterrupted time to make real progress without burning out, while still keeping the quality bar where I want it.
Trying to Learn
I’m sharpening the parts of building that don’t come “for free” from engineering: finding a clear wedge, validating it without overbuilding, and communicating the value simply. I’m also learning to design for longevity- defaults, onboarding, packaging, and operational simplicity - so the project doesn’t become a second job to maintain.
Help Needed
Two kinds of help would move the needle. First: feedback and early users who will be honest about what’s confusing, what’s unnecessary, and what they’d actually pay for. Second: connections to people who’ve built calm, sustainable products - especially those who’ve figured out distribution without turning everything into theatre. And yes, if the right investor or partner showed up, it could buy time and reduce the “do everything alone” tax - but I’m not looking for a rescue. I’m looking for leverage in the form of mentorship, focus, and fewer dead ends.
Can Offer
I’m good at making messy systems reliable. If you’re wrestling with infrastructure, self-hosting, automation, deployments, “why is this flaky,” or turning a fragile setup into something boring and dependable, I can help. I’m also happy to review architecture, threat-model choices, and operational trade-offs - especially for founders who want to stay scrappy without building a future maintenance nightmare.
Read Thomas's full interview
Discover their complete journey, challenges, and insights in our in-depth interview.
Read Interview