Nobody asked me to do this
I could hide the process. Most agencies do. You get a polished landing page, a "book a call" button, and maybe a case study with the numbers filed off. The actual work — the failed automations, the API that returned garbage for three hours, the client who wanted something that didn't make sense until we talked it through — none of that makes the cut.
I do the opposite. This blog is basically my dev diary with the client names removed. When n8n breaks in a way that makes no sense, I write about it. When I switch a workflow from polling to webhooks because the polling was costing someone money in API calls, I write about that too. Nothing here is written to make me look smart. It's written because it's what actually happened that week.
Why transparency beats a sales page
Here's the thing about being a solo dev who sells automation systems to plumbers and electricians: nobody in that world has a framework for evaluating me. They can't read my code. They don't know what a good Supabase schema looks like versus a bad one. What they can do is read a post where I explain exactly why I chose Claude over a cheaper model for a specific task, or why I built retry logic into a Twilio webhook after it silently failed on a client during a holiday weekend.
That's not marketing copy. That's evidence. And evidence builds trust faster than any testimonial page, because testimonials are curated and a build log is just... true.
If you can explain your failures in public, your successes are automatically more believable.
I've had prospects tell me they read four or five posts before ever booking a call. Not because the posts were selling anything — most of them barely mention Radar at all — but because by the time they reached out, they already trusted that I knew what I was doing. The sales conversation is short because the trust-building already happened, for free, over a few blog posts.
The blog is proof of the system, not just a description of it
Here's the part people don't expect: this blog isn't hand-written and manually published like it's 2012. The pipeline that generates and ships these posts is the same category of system I build for clients — an n8n workflow pulls context from real projects, Claude drafts the post, it goes through a review step, and it lands on a Next.js site hosted on Vercel without me touching a CMS.
If I'm telling tradespeople that AI can answer their phones reliably and handle real business logic without a human babysitting every step, the least I can do is prove that same philosophy works on my own content. I'm not asking anyone to trust an idea. I'm showing them a working example, publishing on its own, week after week.
That's the real pitch buried in all of this: automation isn't scary or unreliable when it's built right. It's just infrastructure you stop thinking about. The blog runs itself. Radar answers calls and books jobs without a human in the loop. Taskline generates proposals and tracks jobs without someone manually updating a spreadsheet. Different problems, same underlying belief — if you design the system well, it doesn't need you standing over it.
Both products came out of this exact habit
Neither Radar nor Taskline started as a business plan. They started as "I built this for one client, and it worked so well I wanted to write about why." The writing forced me to articulate what actually made the system valuable — not the tech stack, but the outcome. Radar exists because I kept noticing the same problem across trade businesses: missed calls are missed revenue, and hiring a full-time receptionist doesn't pencil out for a two-truck plumbing outfit. Taskline exists because job tracking for small service businesses was either a $200/mo enterprise tool built for teams of fifty, or a notebook in the truck.
Writing about the problem publicly, before I had a polished product, meant I got real feedback early. People commented, emailed, told me what was missing. The product got better because the process was visible, not hidden behind an NDA and a beta waitlist.
What "building in public" actually costs me
I'm not going to pretend there's no downside. Sharing my actual approach means competitors can read it too. Someone could take a post about how I structure a Copilot Mode integration in Radar and go build something similar. That's a real risk, and I've made peace with it, because the alternative — building in a locked box and hoping the sales page does the convincing — doesn't work for a solo dev with no marketing budget and no sales team.
My advantage was never that nobody else could figure out the tech. It's that I've already done it, in production, for real businesses, and I can prove it with receipts. Ideas are cheap. Shipped systems that survive a Saturday night emergency call are not.
Why this matters if you're the one reading it
If you're a plumber or an electrician or you run a small property management company, you're not evaluating me on my ability to write clean TypeScript. You're evaluating whether I'm going to disappear after you sign a contract, whether the thing I build will actually work when a customer calls at 11pm with a burst pipe, and whether I'll tell you the truth when something breaks.
The blog is how I answer that question before you ever ask it. Every post is a small, verifiable data point: this is how I think, this is how I debug, this is what I actually charge attention to when I'm building something for a client instead of for a portfolio piece.
That's the whole philosophy. No funnel, no growth hacking, no "content strategy" beyond telling the truth about the work as it happens. If that's the kind of person you want building your phone system or your job pipeline, reach out — or just go read a few more posts first. Either way works for me.
