The worst feeling for a technical founder isn’t a bug in production. It’s building a flawless product that absolutely no one cares about.

Every post here is either:

1. A rant about AI
2. AI slop.

This post is number 2, and it's almost formulaic, including the "engagement question" at the end.

I'm uninterested in your AI generated blogspam. Eat rocks and pound sand.

stop offloading your brain to an AI

We need to stop chasing trends and start leveraging our actual advantage: Complexity.

Not quite. Our actual advantage, is our ability to simplify seemingly complex problems.

Now if the expertise is into the architecture of CRUD apps… then crank them out fast for loads of customers! Make a framework that works for you, is resource efficient (saves on server costs), that helps you build finished products that are easily configurable by non-technical customers…

Even the boring stuff may not be as indefensible as it sounds. Sure some LLM can do it quicker and cheaper. But how reliable will it be? How maintainable? I’d wager it still has ways to go on that front.

The only way I’ve avoided the trap is picking problems where complexity, compliance, and ugly integrations are the moat.

Yes-scrapped a slick notes app once I saw CAC rising and clones popping up weekly. Switched to healthcare data plumbing: ingesting EDI/X12, normalizing HL7, adding audit logs and SLAs. Zero ads, sold on reliability and “we passed your security checklist.”

My filter now: talk to 10 target users and get the last 3 workflows they hate; run a paid manual pilot for 2-4 weeks; if they won’t prepay, kill it. Build the outcome first (spreadsheets + scripts), then add queues, retries, idempotency keys, and tamper-proof logs. Price on transactions or compliance saved. For distribution, partner with MSPs and niche consultants already embedded in that industry instead of fighting an attention game.

Starting with Hasura for instant GraphQL on Postgres and Kong for auth/rate limits, I also used DreamFactory when I had to auto-generate secure REST APIs from legacy SQL Server and Mongo across multiple clients.

Bottom line: pick a vertical where the brain-melting plumbing is the value, not a market where the loudest marketer wins.

But what's the use case for a paradigm to leverage the synergies? What kind of end-to-end solution will bring competencies to a performant anachresis?

Yes we are building a heavily architectected new paradigm for backend development. Mention this and almost everyone is skeptical (including us) but we wanted to create React like or Terraform like except for backend logic. There's a huge amount of depth and complexity -- it is basically a compiler -- but a wrapper it definitely isn't. And it definitely can't be done with a prompt or Bolt! 

I was/am a technical cofounder who launched, grew, and eventually exited a business well. It was. 10yr trip and overall went ok, but I think I could have done it in 3-4 if I knew what I knew now back then.

I think there are some merits to your approach, but you're not thinking at "founder level" you're thinking more from an aspirational engineer's seat, so it doesn't read as a voice of experience + track record, more like someone who's got some snippets of the picture sharing what they think it is.

Engineering is rarely what makes businesses successful or salable. We're in an industry that treats engineering as a commodity that can be bought for a price, and in big tech companies it's truly almost never the bottleneck to anything which makes it a poor moat. Engineering is an absolute superpower when starting something new because you can develop much more quickly and iteratively with product-oriented full stack engineers than siloed teams communicating via figma and confluence, but it's not the engineering itself that makes that happen--it's the product orientation.

This is different than how it was 25 years ago when I was first getting going--just the ability to engineer was a huge differentiator and we were in this massive infrastructure building boom where engineers were king. Today? I'd probably try to be a technically-inclined product person. It's a better niche.

Anyways, there are lots of kinds of moats, and I generally would not argue for choosing "technical complexity" as your moat unless your knowledge is truly unique, difficult to replicate or you're leveraging patents/IP stuff.

The best moats are based on relationships. There's a reason B2B is easier than B2C--fewer larger stickier relationships. They can support the business while you take risks. Anyways, we were B2C and did a ton of work on partnerships and partner programs. Once 300 companies have gone through a non-trivial 6-12mo effort to integrate with you, it's much harder for your competitors to repeat that process and it takes a lot of time to drag all of those 3rd parties through it. This is something that large companies mostly cannot speed up, so they will buy you for a time-to-market benefit. Other great moats include data assets and IP.

Medium-good moats include things like deep product expertise. For the areas where I go deep, there's only a handful of people like me. I have a massive advantage launching products that rely heavily on that knowledge because I spent 20 years having those learning experiences and someone else will have to fumble around and waste time. This is the best form of complexity moat, but I'll tell you--it's like 90% product 10% technical in my experience.

Also, since most startups are oriented towards exit, it helps to think up front about what you're providing to your eventual acquirer. There's three classic reasons why companies get bought: time to market, capabilities, and market access. Which one are you? How does that interact with your moats?