Cursor. Lovable. Bolt. Replit. Claude. v0.

A new thing comes out. Someone posts a demo. Someone else says the old workflow is dead.

The founder is left trying to figure out what actually matters.

By the end of this piece, you should have a cleaner way to judge what AI can help you build, where production software still needs human judgment, and why the spec has become the most important artifact in the room.

A founder asked me a question last week that every non-technical founder building with AI is going to ask eventually.

He had a prototype in front of him.

It worked.

The design looked right. The flow made sense. The interaction was there. From his side of the screen, the obvious question was:

Why can’t the developers just use this code?

It is a fair question.

AI tools and design tools are now good enough to create things that feel real. They can generate screens, wire up interactions, produce components, and make a founder feel like the product is closer than it actually is.

That feeling is useful.

It is also dangerous.

Because a software product does not move through one stage. It moves through four.

Prototype. Spec. Production. Refinement.

The prototype answers:

“Does it feel right?”

This is where AI is obviously useful. It can make the idea visible. It can give you screens to react to. It can help you show a flow, test a concept, or explain what you mean faster than a written brief ever could.

A prototype helps the founder say, “Yes, that is closer to what I had in mind.”

That matters.

The mistake is treating that as the finish line.

The spec answers:

“What must it do?”

This is the stage most founders skip because the prototype feels like it already answered the question.

It did not.

The spec defines the product behavior. It names the rules, states, data, permissions, edge cases, error paths, and business logic.

What happens when payment fails?

What does a user see when there is no data yet?

Who can edit this record?

What should never happen?

Which customer action proves this feature worked?

Those decisions need to live somewhere durable. If they stay trapped in your head, the developer guesses. If they stay trapped in a meeting, the team forgets. If they stay out of the prompt, the agent invents.

The spec is the translation layer between founder expertise, developers, and agents.

Then comes production.

Production answers:

“Can customers rely on it?”

This is where the prototype-code question gets real.

A prototype can show the desired interaction. Production software has to connect to real data, enforce states, respect permissions, pass tests, deploy cleanly, monitor failures, recover from mistakes, and keep running when customers are using it.

That is a different job.

A screen that works once in a demo is not the same thing as a system that can run your business.

The last stage is refinement.

Refinement answers:

“How should this improve based on customer feedback?”

Once customers touch the product, the work changes again.

Now you are not guessing from inside the room. You are interpreting signal.

A bug report might be a defect.

It might be a missing requirement.

It might be a confused user.

It might be a customer asking for something that sounds small but breaks the product model.

Founder judgment matters here because feedback is not automatically direction. Someone has to decide what is signal, what is noise, what belongs now, and what belongs later.

That is the part AI cannot own for you.

AI can help across all four stages.

It can help prototype.

It can help draft a spec.

It can help write production code.

It can help summarize feedback.

What it cannot do is replace the founder’s judgment about what matters.

That is the piece non-technical founders are missing when the market keeps shouting tool names at them.

Subscribe now

The founder does not need to become technical.

The founder does need enough fluency to ask better questions.

What stage are we in?

Are we proving the feel, defining the behavior, hardening for customers, or improving from feedback?

What decision is missing?

What risk are we accepting?

What needs to be written down so the team and the agents stop guessing?

That is Founder Fluency.

It is the ability to connect technical work to business risk.

The best AI workflow in the world still needs that.

Because walking away from the build is the fantasy.

Staying in command is the durable path.

Non-technical founders can build real software companies without raising VC, giving away half the business, or learning to code themselves.

The tools are good enough now.

The missing piece is judgment around the tools.

Prototype to make the idea visible.

Spec to define what it must do.

Production to make it reliable.

Refinement to make it better.

Keep your judgment across the whole chain.

That is how AI becomes a way to build your company instead of another thing you are overwhelmed by.

Share

The app hadn’t deployed in two years, and no new contractor would touch it.

The stack was Java on the backend and Angular 1 on the front. A previous contractor team had started a TypeScript rewrite and were six months behind on the delivery.

Two React Native apps sat in the portfolio, a legacy one and a new one. Nobody, including the owner, knew what shipped against what.

Within 90 days, working part-time, I replaced the entire team.

When I got in, the obvious problem was no documentation. Two years of frozen deploys meant whatever institutional memory existed had walked out the door with previous developers.

Underneath the documentation gap was a worse problem. Some of the code had walked out with the developers, literally.

His deployments were going to a cloud account that belonged to a developer who didn’t work for him anymore. Pieces of the software lived in personal accounts under developers’ names. The owner was paying for production infrastructure he didn’t fully control.

He had inherited the configuration that let every developer who touched the product walk off with a slice.

That’s why nobody would touch it. Touching it meant negotiating with people who had left.

The first move was to stop the bleeding. I set up auto-restart on the backend and patched the core issues that had been causing the daily crashes. Within a few weeks, nobody was on restart duty.

The next move was visibility. AI mapped the codebase top to bottom and generated the documentation that nobody had written. Once I could see what existed, I could see what needed to move.

Then came ownership. I traced every piece of infrastructure (code repositories, deployment pipelines, cloud accounts) back to whoever’s account it lived in and migrated it under the owner’s control. By the end of that phase, every piece of his product was actually his.

After ownership came modern delivery. New deployment pipelines lived under the owner’s accounts, configured so deploys could ship without ceremony and roll back without drama.

The last piece was monitoring. Alerts surfaced problems through dashboards, not through customers.

Once the documentation existed and the accounts were consolidated, the team had a fair shot at the new pace. The same AI coding tools I was using were available to them. They could have picked them up and kept up.

They didn’t. Whether they couldn’t or chose not to, the result was the same.

That’s the part a lot of founders don’t see coming. Giving a developer AI doesn’t close the gap if the developer doesn’t pick it up. The tool doesn’t replace the operator.

Ninety days in, the owner cut the standing retainer and off-boarded the original team. The backend that used to crash daily was stable. Issues surfaced through alerts now, not through customer complaints. Shipping was happening again, and the rewrite had a real path forward.

What made the 90-day pace possible was two things together: principal-level strategy applied to the platform, and rapid execution against that strategy with AI agents.

Strategy wit

hout agents would have taken a year, and agents without strategy would have produced more sprawl, not less. The combination is what bent the curve.

This was a live service with thousands of paying users. Pausing it to rebuild was not an option. Every change had to ship without breaking the people already paying.

The problem itself is more common than first-time founders realize. Before AI agents were in the mix, fixing a frozen B2B SaaS like this used to mean two extra developers, $20k-$30k/mo, and a year on the calendar. Now I do it solo. I charge 75% less for the same fix and deliver it 75% faster.

If your product looks anything like this, you’re not stuck. You just need the right system in place.

Dustin Rea runs a solo development practice for non-technical B2B SaaS founders. More at dustinrea.com.

Most non-technical founders find out about email deliverability the hard way.

• A customer says they never got the welcome email.

• A prospect goes silent and you can’t tell if they’re ignoring you or never saw your reply.

• Trial signups drop and nothing on the site has changed.

The root cause is almost always the same.

Your domain is missing the DNS records that tell Gmail, Outlook, and Yahoo you’re allowed to send mail as yourself. Without those records, receiving servers treat your email as suspicious and either filter it to spam or drop it on the floor entirely.

It’s fixable, inexpensive, and not that complicated once you know what you’re looking at.

It just sits on a part of the build that most developers, especially offshore agencies and junior contractors, skip because email infrastructure is a different specialty from writing application code.

If you don’t know to ask for it, you don’t know you’re missing it.

This is a Founder Fluency Pillar 1 gap. Stack, hosting, and DNS sit between your application and the outside world, and the failure modes there don’t show up inside the app where your team is looking.

What deliverability actually depends on

When an email arrives at Gmail or Outlook, the receiving server checks three records on your domain before deciding where to deliver it.

SPF (Sender Policy Framework). SPF is a DNS record that lists which servers are allowed to send email as your domain. If you send through Google Workspace, your SPF record should authorize Google. If you also send transactional email through a service like Postmark or SendGrid, the SPF record should authorize those too. Use one SPF record per domain, with every sender merged into it.

DKIM (DomainKeys Identified Mail). DKIM is a cryptographic signature attached to every outgoing email. The matching public key lives in DNS. The receiving server checks the signature against the public key to confirm the email actually came from your domain and wasn’t tampered with in transit.

DMARC (Domain-based Message Authentication, Reporting, and Conformance). DMARC is the policy that tells receiving servers what to do if SPF or DKIM fail. It supports three modes:

1. p=none (monitor only, deliver as normal)

2. p=quarantine (send to spam)

3. p=reject (don’t deliver at all)

Start at p=none with a reporting address so you can see what’s happening, then move to stricter policies once your DMARC reports are clean.

If any of these three records are missing or wrong, your email looks like spoofing to the receiving server. Gmail and Outlook deprioritize it, filter it to spam, or reject it outright.

From the sending side, the failure is invisible: no bounce, no error message, no signal inside your application that anything went wrong. The email just doesn’t land.

That silence is the part founders underestimate. Most product failures generate visible signal inside your system. Email deliverability lives outside that loop, in receiving servers you don’t control, so the same signals never reach you.

The deadline already passed

Every major inbox provider now treats this as a compliance requirement. In February 2024, Google and Yahoo both started requiring SPF, DKIM, and an aligned DMARC policy for any domain sending more than 5,000 messages per day to personal accounts on their services. Microsoft followed for outlook.com, live.com, and hotmail.com in May 2025, with the same 5,000-per-day threshold.

Gmail spent most of 2024 ramping enforcement gradually. In November 2025, it shifted from temporary delivery delays to outright rejection for non-compliant traffic. Microsoft’s policy went straight to rejection the day it took effect.

Five thousand messages per day sounds like a lot until you do the math. Welcome emails, password resets, order receipts, and a weekly newsletter to a list of 30,000 trip the threshold the day the newsletter goes out, and the Gmail, Yahoo, and Outlook buckets are counted separately. The “we’re too small to worry about this” line stopped working the day those deadlines took effect.

Why your team probably missed it

Setting up SPF, DKIM, and DMARC properly takes about two hours if someone has done it before. It gets missed because the failure happens after the email leaves your application, in receiving servers your team doesn’t control. From the engineer’s seat, everything inside the build looks fine.

Most teams put their review effort into application code, so a DNS configuration that was correct in 2023 stays untouched even as the standards on the receiving side move past it.

If your dev arrangement predates February 2024 and nobody pulled DNS into a review since, you’re almost certainly shipping out of compliance with at least one of the big three inbox providers.

That’s also why this falls cleanly into Pillar 1 of Founder Fluency. Stack and infrastructure questions are the ones a founder can’t diagnose by looking at the app, because the app isn’t where the problem is.

A founder who knows enough to ask about the DNS records catches the gap in one conversation. That single question is the difference between a fixed problem and months of silent revenue.

Four questions to ask your dev

1. “Show me our SPF, DKIM, and DMARC records on our sending domain.” They should be able to produce these in five minutes. If they have to ask what those are, that’s information.

2. “Run our domain through mail-tester.com. What’s the score?” Mail-tester is free. You send one email to the address they give you, and the tool grades it out of 10 with specific notes on what’s wrong. You want 9/10 or 10/10. Anything lower means something is misconfigured.

3. “What’s our DMARC policy?” At minimum p=none with a reporting address like rua=mailto:youraddress@yourdomain.com so you can see authentication failures as they happen. Better is p=quarantine or p=reject after a few weeks of clean reports.

4. “Are we sending transactional email and marketing email from the same domain?” Usually you don’t want to be. Marketing email gets more spam complaints, more unsubscribes, and more aggressive filtering, which means your transactional email (password resets, order receipts, the stuff customers actually need) inherits the worse reputation. Most teams send transactional from the main domain (yourdomain.com) and marketing from a subdomain (mail.yourdomain.com or news.yourdomain.com).

What to do this week

If you’ve never checked any of this, run the test yourself. Send an email from your business domain to a personal Gmail account. If it lands in spam, in Promotions, or nowhere at all, you have a problem that’s almost certainly costing you deals you’ll never hear about.

Then run mail-tester.com on the same sending address. If you score below 9/10, the tool tells you exactly which records are missing or wrong. Hand that report to your developer.

Verify someone set the three records up correctly, then check the score periodically as you add new sending services. The cryptography itself isn’t your job to understand.

If a developer can’t answer the four questions above, or waves them off as “not important right now,” that’s information about how the rest of your platform is being built. The whole point of Founder Fluency is that you don’t have to take on faith what your team is doing. You can ask one specific question and judge whether the answer holds up.

Email deliverability is the cleanest example of why that matters: two hours of dev work prevents months of silent revenue loss you’d only catch when a customer happens to mention it.

Sources

• Google, “Email sender guidelines” (Google Workspace Admin Help): support.google.com/a/answer/81126

• Google, “Email sender guidelines FAQ” (November 2025 enforcement update): support.google.com/a/answer/14229414

• Yahoo Sender Hub, “Sender Best Practices”: senders.yahooinc.com/best-practices

• Yahoo Postmaster blog, “More Secure, Less Spam: Enforcing Email Standards” (October 2023 announcement of Feb 2024 enforcement): blog.postmaster.yahooinc.com

• Microsoft, “Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders” (Microsoft Community Hub, April 2025): techcommunity.microsoft.com

• SPF (Sender Policy Framework): RFC 7208, April 2014

• DKIM (DomainKeys Identified Mail): RFC 6376, September 2011

• DMARC (Domain-based Message Authentication, Reporting, and Conformance): RFC 7489, March 2015

• Mail-Tester: mail-tester.com

This post covers the general opinions I carry right now. If you’re a non-technical SaaS founder trying to figure out where AI fits in your dev arrangement, this is for you.

The thesis is:

managing AI coding agents is the same skill as managing developers.

If you can do one, you can do the other.

The corollary nobody is saying out loud is that non-technical founders have an unfair advantage with agents, because they’ve already been forced to learn how to delegate without prescribing.

I spent the last several years running an agency that delivered production B2B SaaS with human engineers before AI and then a mixed team of human engineers and AI agents.

What surprised me was that the management discipline turned out to be the same one I’d been teaching non-technical founders the whole time.

Here are the five themes I continue to see repeating..

1. The prescription trap

The most common failure mode for technical people with AI agents is the same failure mode product managers have with engineers. They tell the agent how instead of what.

Vague prompts produce garbage. Too-literal prompts also produce garbage, because the agent’s ability to make tradeoffs has been stripped out.

The skill is being precise about what you want and loose about how it gets done. That’s the whole game.

2. Completed staff work

Don’t let the agent jump straight to code. Make it research the problem, propose three options, and recommend one. It’s the same thing you’d ask of a good junior dev: come back with options and a recommendation, not a question.

This habit forces the agent to surface assumptions you didn’t realize you were making. You catch the wrong premise in the planning step, where rework costs minutes. Catching this at the end in testing wastes time and tokens.

3. Demo the result, don’t read the diff

With human developers, you might read the pull request. With AI agents, you can’t. They ship ten times the code. The workflow non-technical founders use already scales for this: have the agent demo the working thing.

The deeper point lands hardest with technical founders. Non-technical founders were forced into this discipline years ago because they couldn’t read code. Now technical founders are catching up to a habit they used to look down on.

That doesn’t mean skip code review. In a healthy setup, every pull request runs through static analysis and a review agent first. A human reads the pull requests that touch Mission Critical Paths.

4. Principles are not prescriptions

This is the line founders miss. “Don’t prescribe” doesn’t mean “no guardrails.” It means the opposite. You need strong principles, baked into the architecture, that constrain the solution space without constraining the solution.

A principle constrains the solution space. A prescription constrains the solution.

Two concrete examples:

• Full-stack TypeScript when building a web app, unless there’s a real reason not to. One type system spans webapp, API, mobile, and every other client. The agent and every human on the team operate from one mental model.

• A design system with reusable components. That means a good table view, a data viewer, and form primitives. The agent composes new screens from existing parts instead of hand-writing every table; the UI stays visually consistent for free.

Layer hard requirements on top. Junior devs need rules. Senior devs need principles. AI agents need both, plus a small list of non-negotiables (never commit secrets, never skip tests, never touch production directly) that act as the floor.

5. Decompose, one-shot, compose

Big tasks produce slop. The agent can actually nail a small, bounded job. Decompose the work into bounded pieces, one-shot each one, then compose the results into production-quality work. Ask it to “build the whole feature” and it loses the plot, the same way a junior dev crushes tickets and chokes on epics.

The same pattern applies to building a team. Founders go hunting for the unicorn who does design, ops, sales, and product. That person doesn’t exist, or costs a fortune, or burns out. The real answer is a small team of specialists, each excellent at their one thing, with clean handoffs between them.

Whether the unit is a prompt, a service, or a person, the principle is the same.

Watch the Full Episode of Never Rewrite

What’s next

This is the working summary. The deeper essay, on where the “Dark Factory “ pattern came from, who’s publicly building it right now, and how I’m using the pattern to rebuild my agency, lands on Better Every Cycle next week.

Subscribe if you want the long version when it drops.

In the meantime, the full conversation is here: Never Rewrite - Agentic Development Is Turning Engineers Into Product Owners

Principal Software Engineer at Google - Adam Bender on staffeng.com

Question for Staff+ Did you do a “Staff Project”? Did it land perfectly or need some refinement?

I talked a little about the experience of my “Staff Project” in the annotated notes in the link above.

TLDR is that Staff Projects are big and ambitious and typically involve a lot of communication, planning, and reflection in hindsight on what could have gone better.

The Best of What I Read Last Week

This is a curated list of reads from last week. It is not exhaustive, in any order, or based on what was actually published last week. This list is content that I consumed and felt worth sharing with people who would read my newsletter.

• Finding my voice with a series of dials

• Auto-Tagging Releases with SemVer in Github Actions

• OAuth 2.0 vs OpenID Connect

• Never Rewrite - Episode 46: Workshopping Solutions for a Growing CRM SaaS product

Last week I was on the Never Rewrite Podcast with Isaac Askew and Jeffrey Sherman discussing scale and quality issues for a CRM SaaS. Check out the chapter list below to jump straight to a topic you’re interested in:

Chapters

• 00:00 Introduction and Background

• 01:12 The Current State of the White Label CRM

• 06:11 Goals and Expectations for the Project

• 07:54 User Trust and Importance of the CRM

• 10:44 Focus on Email and SMS Issues

• 13:30 Importance of User Support and Community

• 16:36 Email and SMS Deliverability Challenges

• 19:46 Database Structure and Performance Challenges

• 20:13 Improving Write Efficiency

• 21:02 Using SQS and SNS for Message Queuing

• 22:03 Controlling Flow with Multiple Readers

• 23:05 Writing to Separate Databases

• 24:01 Tracking Heavy Queries

• 25:37 Separating Permissions and Heavy Reads

• 26:08 Caching with Redis

• 27:05 Improving Email Service Reliability

• 29:02 Monitoring and Alerting

• 30:28 Improving Data Logging and Validation

• 32:15 Implementing a Defined Process for Email Service

• 33:09 Recording and Rebuilding Failed Email Requests

• 35:11 Setting Up Aggregated Logs and Monitoring

Thanks for reading!

Hi I'm Dustin Rea and this is D-Rea's Newsletter.
A newsletter for humans working in Tech.

At the time of this writing, I am a software engineer working at an AI company and I also operate a software design and development agency that works with SaaS companies, most of which are trying to leverage AI. My opinions are my own.

Not going to lie, I was a little nervous when I first saw Devin AI, as most of you reading probably were as well. That's why my clickbait title worked.

However, I try to keep my future Terminator nightmares at bay by remembering timeless principles about society that date back thousands of years.

TLDR

AI is another advancement that is already shaping the way we work. Notice I said we work. Because someone will need to solve problems, make decisions, or lead others using AI at the very least. Also, people thrive on human connection so I predict entertainment as a profession will be safe for years to come.

Healthy Comparisons

The Quantum Computer is also talked about in a similar way to AI. It will fundamentally change what is possible. For some people that is scary, because that means they will have to change what they are doing. Change can be scary and bad.

Change can also be exciting and good. If we didn't have change, we wouldn't have Amazon shipping packages to your door steps in two days, most of the time.

Without change we wouldn't have the internet or the iPhone. Both of which were used to completely change industries. In the same light, they created new opportunities.

Cloud Solutions Architect wasn't a job until the concept of the cloud existed. Mobile App Developer wasn't a type of Software Engineer prior to the iPhone1.

Software Engineer or Clown

Keep the MacBook, For Now

I think that even if software engineering is going to fade away as the profession it is today, a new profession for engineering types will pop up. In the meantime, there is a massive amount of work to do maintaining legacy software that keeps the world running. There will be mountains of work to do even with AI helping us to start shifting that software to the new AI paradigm.

Humans don't change overnight, it will take time and effort and we should seize the opportunity, just like every other advancement.

Know a software engineer going through an existential crisis? Send ‘em my way and I’ll try to talk them down from the ledge. Keep Building!