If I Started Building SaaS With AI Again Tomorrow, I’d Do These Things Differently

I would still use AI

If I could start my AI-assisted SaaS journey again tomorrow, I would still use AI heavily. I would still build, experiment and move ideas from conversation to working software far faster than would have seemed realistic only a few years ago.

What I would change is not whether I used AI. I would change how I decided what deserved to become software in the first place.

Building dozens of SaaS tools taught me that when one constraint disappears, others become more visible: maintenance, focus, architecture, customer demand, product overlap, backups, version control, documentation and integration complexity.

1. Start with the problem, not the product

I would begin with who has the problem, how often it happens, what people do now, what it costs in time or frustration and why existing solutions are not enough. Only then would I think about software.

A problem may need a feature, automation, guide, integration, shared service, better process or nothing at all.

2. Make a new application earn its independence

Before creating a new SaaS I would ask whether the capability could be a feature inside something I already own. A new application means another database, login, domain, settings area, backup, update path and security surface.

A new application should have to earn its independence.

A new application should have to earn its independence.

3. Design shared services earlier

Email, customer data, authentication, access, research, analytics and notifications can appear repeatedly. The second time I needed the same capability I would ask whether it should become shared infrastructure.

The goal is simple: build once, improve once, reuse many times.

4. Version everything from day one

Every application would begin with a visible version number. Every patch would know what version it expects, every update would record what changed and every developer snapshot would identify the version it contains.

If something goes wrong I want to be able to answer exactly what was running before the update.

5. Backup and restore before clever features

Before another AI generator, dashboard or automation I would want to know that I can back the system up, restore it, create a known-good snapshot and recover from a failed patch.

Building quickly is only truly useful when you can recover quickly.

6. Make controlled patching part of the foundation

Replacing files manually can work when software is tiny. It becomes dangerous as the product evolves. A proper patch should understand current version, expected version, file changes, database changes, rollback requirements, unsafe paths and installed history.

7. Document while the context is fresh

There is a dangerous sentence in software development: “I will remember how this works.” You probably will for a while. Then you build something else.

I would document purpose, architecture, integrations, important tables, external services, configuration, backup process, update process and major decisions as part of finishing the feature.

8. Preserve better context for AI

AI becomes dramatically more useful when it works from reality rather than memory. If I ask for help with a product, I want the current application, the current database changes and the actual installed version available.

AI can reason well over accurate context. It cannot reconstruct context that was never preserved.

9. Set a higher bar for features

AI makes feature development cheap enough that almost every suggestion sounds reasonable. I would pause before new features and ask who needs it, how often, what happens if I do nothing, whether it creates support, whether another product already solves it and whether I still want to own it in two years.

The easiest feature to maintain is the one you never added.

10. Put smaller versions in front of users earlier

AI makes polished first versions possible, which can become a disadvantage because you keep improving before anybody proves they care. I would show useful but intentionally limited versions earlier and use behaviour to decide what deserves to grow.

11. Ask for problems instead of ideas

If you ask “what SaaS should I create?” you get solutions. If you ask “what task wastes your time every week?” you get problems. Problems are far more useful because they leave room to think.

12. Separate interest from demand

People will say an idea sounds good, vote for it and tell you they would use it. That is interest, not proof of demand. Real demand appears when somebody gives up something: money, time, an existing workflow, data or effort.

13. Treat attention as a business cost

Hosting, AI tokens and domains are measurable. Attention is harder to quantify but may be the most expensive resource for a solo founder. Every product, bug, integration, patch and server warning consumes some of it.

I would evaluate software partly by value produced divided by attention consumed.

14. Kill experiments faster and delete more

AI reduces the cost of starting, so I would also reduce the emotional cost of stopping. An experiment has done its job when it produces useful information. If the answer is that nobody wants it, the problem is too small or the maintenance is not justified, stopping is sensible.

I would also deliberately remove old test pages, unused tools, duplicate functionality, abandoned prototypes, inactive subdomains and forgotten scheduled tasks. A smaller portfolio that I understand is better than a larger one I have forgotten.

15. Think about security and failure earlier

Working and secure are not synonyms. Authentication, file uploads, admin tools, patch installers, API keys, webhooks, customer data and database queries need explicit security thinking.

I would also design for failure: assume an API will fail, an email will not arrive, a migration will stop halfway through and an external service will change. Then ask whether the system fails safely and whether recovery is obvious.

16. Prefer boring technology more often

AI makes sophisticated architectures easier to implement, but sometimes boring is better: PHP, MySQL, straightforward APIs, simple scheduled jobs and tools that can be understood six months later.

Complexity should have to earn its place, especially when one person ultimately owns the result.

17. Use AI to disagree with me more

It is easy to use AI as confirmation: I want to build this, tell me how. Instead I would deliberately ask why it is a bad idea, what I am underestimating, what a sceptical customer would say and what existing solution makes the build unnecessary.

Agreement feels good. Disagreement can save months.

18. Bring distribution into product thinking earlier

A product does not become a business because the software works. Somebody has to discover it, understand it, trust it and want it. Before building I would ask where the first users come from, whether I can describe the benefit in one sentence and whether I already know people with the problem.

19. Measure usage earlier

What people say matters. What they do usually matters more. Did they log in again? Complete the workflow? Use the core feature? Come back next week? Recommend it?

You do not always need complicated analytics. Sometimes you simply need to know whether anyone came back.

20. Build more experiments and fewer platforms

The word platform can encourage premature complexity. I would be more likely to say “let us solve this one problem extremely well” and let larger structures emerge only when the smaller pieces have earned them.

The biggest change would be my definition of progress

At the beginning, progress can feel like more apps, more features, more code and more integrations. Now I would measure it differently: fewer duplicated systems, safer updates, better backups, clearer customer journeys, more reuse, more real usage, less maintenance, stronger products and more things deliberately not built.

The fastest path is not necessarily the one that produces working code first. It is the one that produces the least regret later.

The fastest path is not necessarily the one that produces working code first. It is the one that produces the least regret later.

What I would tell someone starting tomorrow

AI will probably allow you to build much more than you expect. Do not confuse that with needing to build all of it.

Start small. Preserve context. Back things up. Keep versions. Listen to real problems. Challenge your ideas. Reuse what works. Remove what does not. Treat maintenance as part of the product and remember that every successful build leaves you owning something.

The next stage of AI-assisted SaaS is not simply about generating better code. It is about developing better judgement.

AI will probably allow you to build much more than you expect. Do not confuse that with needing to build all of it.