When I decided to launch Worqship, I made a commitment to build in public. Not the polished, curated version of “building in public” that only shows up and-to-the-right revenue graphs, but the actual reality of launching an independent software studio.
This is the retrospective of our first month. The numbers, the mistakes, the unexpected wins, and the validation of the “utility-first” software philosophy.
The Launch Strategy (Or Lack Thereof)
There was no Product Hunt launch. There was no paid ad campaign. There was no coordinated PR push.
The strategy was incredibly simple: publish a few high-quality, opinionated essays about why modern SaaS is bloated and why internal tools are overpriced, and share them in places where founders and operations managers actually read things.
I shared the posts on LinkedIn, a few niche Slack communities, and Hacker News. The goal wasn't virality; the goal was resonance. I wanted to see if the phrase “utility-first software” actually meant anything to people outside of my own head.
The Numbers: Month One
Here is exactly what the traffic and conversion funnel looked like in the first 30 days:
- Unique Site Visitors: 4,218
- Average Time on Page (Blog): 4 minutes, 12 seconds
- Contact Form Submissions: 34
- Qualified Leads: 12
- Signed Contracts: 3
A 0.8% conversion rate from visitor to lead might sound low in the e-commerce world, but in the B2B custom software space where project sizes are in the thousands, 34 inbound inquiries for a brand new, one-person studio is an overwhelming success.
What Worked: The Philosophy Resonated
The most surprising data point wasn't the traffic volume, but the time on page. An average read time of over 4 minutes means people weren't just skimming the site; they were actually reading the arguments against bloated software.
In almost every discovery call with the 12 qualified leads, the client explicitly referenced the blog posts. They said things like:
“We read your post about replacing Google Sheets. That is exactly where we are right now. We are drowning in tabs and we need a focused tool.”
Takeaway: Having a strong, opinionated point of view is a better marketing strategy than having a massive budget. By explicitly stating who Worqship is NOT for (enterprises looking for massive, bloated platforms), it made the people we ARE for (teams needing focused, fast utility software) trust us immediately.
What Failed: The Initial Pricing Structure
My biggest mistake was my initial approach to pricing.
In the first week, when leads asked for a quote, I tried to give them a precise fixed price on the very first call based on a 30-minute conversation. This was a disaster.
I underestimated the complexity of two projects because I hadn't seen their data structures yet. I had to go back to those leads three days later and revise the quote upwards, which eroded trust. Neither of them signed.
The Fix: I immediately changed the process. I now refuse to give a final fixed price on the first call. Instead, I give a “ballpark tier” (e.g., “This sounds like a Tier 2 project, between £6k and £10k”). I only provide a fixed quote after a dedicated, paid scoping session where we actually map the database architecture. Since implementing this, the close rate has skyrocketed.
The Technical Stack Held Up Perfectly
On the engineering side, the decision to stick to a “boring” but incredibly robust stack paid massive dividends.
The Worqship site, and the first three client projects, are all built on Next.js, Tailwind CSS, TypeScript, and Supabase.
There was a moment on day four when a post got picked up in a large tech newsletter, sending a massive spike of concurrent traffic to the site. The Next.js static generation handled it flawlessly. Zero downtime. Zero latency spikes.
When you are a solo operator, your infrastructure has to be invisible. You cannot afford to spend hours managing DevOps when you should be writing code for clients. The stack worked exactly as intended.
What Comes Next?
Month two is about delivery. With three client projects actively in the build phase, marketing takes a back seat to engineering.
The focus now is on proving that the “utility-first” philosophy works in practice, not just in essays. That means delivering these three internal tools on time, within the fixed scope, and ensuring they are blisteringly fast and simple to use.
I will be writing case studies on all three projects once they launch, breaking down the exact technical architecture used to solve their specific business problems.
Thank you to everyone who read, shared, and reached out during month one. If you are a founder or operator looking to build a focused internal tool without the agency bloat, the workshop is open.