I want to tell you the honest version of this story. Not the polished “founder finds gap in market, pivots to success” version. The real one.
It starts with a client project I should never have taken.
The project that broke something
Three years ago, a client hired me to build them an internal dashboard. Simple brief: pull data from three sources, display it cleanly, let the team filter by date range and region. Six weeks, reasonable budget, clear scope.
I delivered it in five.
Then the scope changed. New data source. New filter. New user role with different permissions. “Just small changes,” they said. “Shouldn't take long.”
Four months later I was still on that project. The “simple dashboard” had become a miniature ERP system. The codebase was a mess of last-minute additions, each one logical in isolation, collectively incoherent. The client was frustrated because it was slow. I was frustrated because I'd built something I was no longer proud of.
I got paid. The client got something that worked, mostly. But nobody walked away feeling like a problem had been solved.
That project ended and I took a week off to think.
The pattern I kept seeing
The more I paid attention, the more I saw the same story everywhere.
Companies using spreadsheets with forty-seven tabs because the “proper” tool was too expensive or too complicated. Developers writing the same boilerplate for the fifteenth time because no one had built the right abstraction yet. Founders buying enterprise software for small-team problems, then using 8% of the features and paying for the other 92%.
The tools that existed were either too simple or too complex. Too cheap to trust or too expensive to justify. Built for a general audience that included everyone and therefore fit no one precisely.
And the agencies and studios that could build the right thing? Most of them operated on a model that required three discovery workshops, a 40-page proposal, and a six-month timeline before writing a single line of code.
There was a gap. A real one.
What I actually wanted to build
Not an agency. Not a product company. Something in between.
A workshop.
The word means something specific to me. A workshop is where precise things get made by people who know their tools. It's not a factory — it's not optimising for volume. It's not a consultancy — it doesn't bill you for thinking about your problem. It makes things.
The idea was simple: build focused, utility-first software tools that people could buy and use today, and take on client projects where the problem was real and the solution needed to actually ship. Two channels, one philosophy.
The philosophy: every piece of software that leaves this workshop does one thing, solves it completely, and doesn't apologise for not doing the other things.
I called it Worqship. Workshop. Work. Ship. I like names that mean something.
What I was afraid of
I'd be lying if I said I just launched confidently and figured it out.
I spent a month talking myself in and out of it. The questions that kept me up: who's going to trust a one-person studio over an established agency? How do you compete with the cheap offshore options that undercut on price? What if the first product doesn't sell? What if the first client hates the work?
The answer I kept coming back to was: I can't know any of that until I build something and show it to people.
So that's what I'm doing.
The bet I'm making
The bet is that there are enough people — developers, small teams, startup founders, ops managers — who are sick of the same things I'm sick of.
Sick of bloated software that charges enterprise prices for features you'll never use. Sick of agencies that scope your project to death before building a thing. Sick of tools that do everything except the specific thing you needed.
If that's you — if you've ever looked at the state of your toolbox and thought “there has to be a better option for this specific problem” — then Worqship is being built for you.
Not for everyone. For you.
What comes next
I'm building in public. That means sharing what's working and what isn't, what shipped and what broke, what the numbers look like and where the gaps are.
Not because transparency is trendy. Because I think it's the right way to build trust with the people who'll eventually use what I make. You shouldn't have to buy blind. You should be able to watch something get built and decide for yourself whether the person building it thinks like you do.
The first tools are coming. The workshop is open for client projects now.
If you've got a problem that's been sitting on your to-do list because the off-the-shelf options don't fit — come and tell me about it.
Let's build the right thing.
Following the build? Start a project →