No algorithm decides what you read. Read the Substack →
00 / Cold open
Technical & product strategy for non‑technical founders

Your product doesn't have a techtranslation problem.

You hired smart people. You followed the process. And you still ended up with something bloated, confusing, and disconnected from the person who's supposed to pay for it.

That's not bad luck. It's what happens when nobody in the room speaks both languages: what the business needs, and what actually gets built.

01 / The symptom

You can tell something's wrong. You just can't tell what.

The agency delivered on time and on spec, and somehow you ended up with fourteen settings screens, three onboarding flows, and a codebase so tangled that every "quick fix" is now a three-week change order. Or you went the other way: you built it yourself with AI tools, it worked, right up until it didn't, and now nobody, including the AI, can tell you why.

Real customers open it and hesitate. They click the wrong thing, or the right thing twice, or they just leave. Something's off, but you don't have the vocabulary to name it, and every developer you ask says it's "fine."

And underneath both of those: you haven't talked to ten customers this month. Maybe not this quarter. You're guessing at the roadmap from inside a Slack channel, and the numbers you do have don't explain why growth stalled.

None of this is because you're not technical. It's because "what the business needs" never got translated into "what gets built," and back again.

02 / The other timeline

Picture the version where this actually works.

A product simple enough that a new user gets it in the first thirty seconds: no tour, no tooltip, no "let me show you around." A codebase your next developer can open without groaning. A standing rhythm of real conversations with real customers, so the roadmap is built from evidence instead of vibes.

And you, in every meeting with a developer, an agency, or an investor, asking the sharp question before they've finished explaining the wrong one.

None of that requires you to learn to code. It requires someone in your corner who already can, and who's spent enough time with actual customers to know that clever and simple are usually two different things.

03 / How this works

Here's what working together actually looks like.

This isn't a course, and it isn't a dev shop. It's a second set of eyes (technical, product, and UX) sitting on your side of the table.

The Audit (one-time)

A structured teardown of what you've already built. I read the codebase (or have it read), use the product like a first-time customer, and sit with your usage data. Then I hand you a plain-English report: what's load-bearing, what's bloat, what's actually confusing customers, and what to fix first.

Delivered as a written report plus a call to walk through it.

Turnaround: two weeks, start to finish.

The Advisory (ongoing)

For founders who want that second set of eyes permanently, not just once. A recurring session every week or two, reviewing what shipped, what customers said, and what's next, plus async access in between for decisions that can't wait for the next call.

Think fractional CTO, minus the fluff and the full-time salary.

Cadence: month to month. No lock-in.

Every product's starting point is different, so the investment gets scoped to what yours actually needs. That's the first thing we work out on the call, before anything's signed.

04 / First step

Find out what's actually going on before you spend another dollar guessing.

Book a Product Diagnosis Call →

30 minutes. If I don't think I can help, I'll say so in the first ten, and point you toward someone who can. No pitch deck, no hard close.

05 / What founders say

Early days. This row is reserved for their words, not mine.

Real quotes go here once the first few engagements wrap. Nothing invented in the meantime.

[ ] testimonial slot: name, company, and the specific result they'd credit.
[ ] testimonial slot: quote that pre-empts a skeptical reader's objection.
[ ] testimonial slot: a founder describing the before/after in their own words.
06 / Fair questions
I already have a developer or an agency. Why do I need this too?

You probably don't need to replace them. You need someone who isn't billing you by the hour to tell you whether their advice is actually in your interest. I don't build; I evaluate, translate, and advise. Most clients keep their existing team and just make better decisions about how to use them.

Can't I just ask ChatGPT or Claude about this?

You can, and you should, for a lot of it. Where it falls short is judgment calls that need context an AI doesn't have: your actual customers, your actual codebase, your actual constraints. I use AI tools daily in my own work. This is what happens when someone who does that full-time also sits down with your specific product.

What if the answer is "you need to rebuild it"?

Sometimes it is, and I'll tell you, but it's rarer than founders fear. Usually the fix is subtraction: cutting the features nobody uses, simplifying the flow that's losing people, fixing the three things that are actually broken instead of the fourteen that feel broken. A rebuild is the expensive, sometimes-avoidable last resort, not the first suggestion.

I don't have a big budget for consultants.

Neither did most of the founders I've worked with. That's why the first step is a scoped audit, not an open-ended retainer. You get a specific, priced deliverable before you commit to anything ongoing.

How is this different from just hiring a CTO?

A full-time technical hire is the right call eventually, just not yet. This is that judgment, available before you can justify or afford the salary. And it doesn't disappear the day you do make that hire; it just becomes the handoff.

What if I don't like what I hear?

That's kind of the point. An agency that built it, or a developer you're paying, has a reason to tell you it's fine. I don't have that conflict. You're paying for the honest version.

07 / Why me, specifically

Most "technical advisors" are one of two things.

Either they can talk business strategy but couldn't open your codebase if you paid them, or they can code but think UX means picking a nicer font. I've spent my career on both sides of that line: reading and writing the code, and sitting with the customer trying to use what it produced.

I also build and ship my own products, so every recommendation I give you has been stress-tested somewhere other than a slide deck.

There's no bench. No account manager, no junior analyst doing the actual audit while a partner presents it back to you. You get me, directly, on every call and every review.

08 / Second chance

You've read this far. That's usually a sign it's actually you.

Book a Product Diagnosis Call →

Same 30 minutes, same rules: honest answer, no obligation.

09 / One catch

I take on three advisory clients at a time.

Not a marketing trick. An audit or an ongoing advisory relationship only works if I've actually spent real time in your product and your data, and that doesn't scale past a handful of founders at once. Audits run separately and open more often; advisory seats are the limited part.

If a seat isn't open when you reach out, I'll tell you straight, and either waitlist you or point you elsewhere. Better than pretending I have bandwidth I don't.

Ready when you are: feargswalsh@gmail.com, or book the call directly above.