How to Choose a Tech Stack for a SaaS When You Can't Code

The very first saved change in the KashBoss project, on December 24, 2025, contained 139 files. Most of them I would not have understood if I had opened them. But the folder names told a story: android, ios, web, windows, macos, linux. From the first minute, the same project knew how to become a website, a phone app and a desktop program.

Nine months later, on October 3, 2026, that choice paid off in a way I had almost forgotten to expect. I had paid for an Apple developer account but did not own a Mac. We set up a cloud build service, pressed one button, and six minutes later the iPhone version of KashBoss, built from the same code that runs our website and our Android app, was uploaded to Apple. No rewrite, no second team, no new language.

Choosing your tools is one of the few decisions that is expensive to change later, so it is worth getting right.

The short answer

Choose popular, managed tools that reach every platform you need from one codebase, store your data in a real relational database with security rules, start near zero cost, and let you take your code and leave. For a business system used on desktop and phones, we chose Flutter for the screens, Supabase for the back end, and Cloudflare and GitHub for hosting. For a content website that lives on search traffic, you should choose differently.

What a "stack" is

The set of tools a product is built with is called its stack. Think of a restaurant:

• The dining room is what customers see and touch: screens, buttons and forms. This is the front end.
• The kitchen and pantry is where the work happens and everything is stored: the database, business rules and security checks. This is the back end.
• The building and street address is where it lives and how people find it: hosting and a domain name.

Six questions to judge any tool

When an AI assistant writes the code, judge each tool by these:

1. Is it popular? AI assistants learned from public code. The more people use a tool, the better the AI knows it and the fewer strange mistakes it makes.
2. Does one codebase reach every platform you need? Every extra codebase is extra work on every change, forever.
3. Is it managed? You want services that run the servers for you, not a server you must patch at night.
4. Does it have a real database with rules? Money needs a database that can enforce rules and do several things as one unbreakable operation.
5. Does the cost start near zero and grow with use? You should not pay hundreds a month before your first customer.
6. Do you own the code? If the company disappears or doubles its price, can you take your code and leave?

Choose boring, popular tools. The AI knows them better, and they will still exist in five years.

The front end: Flutter

Flutter is a free toolkit from Google for building apps. You write the app once, in a language called Dart, and Flutter turns it into a website, an Android app, an iPhone app and a desktop program. It draws every pixel itself, so screens look the same everywhere, and it handles right-to-left languages such as Arabic well, which our interface needs.

It also came with costs that nobody warned me about. "One codebase" did not mean "one set of screens." We built separate web pages and mobile screens that share the same logic underneath. That let a wide desktop cashier and a thumb-sized phone screen each have their own layout, but it doubled the work on every visible change. It became one of my strictest rules: any change to a screen is made on web and mobile together, in the same update.

The rule we follow now is to check which platforms a package supports before adding it, to load phone-only packages through a separate file the website never sees, and to treat a green check on my own computer as no proof at all. Only the real build that deployment runs counts.

The back end: Supabase

Supabase is a managed back end built on PostgreSQL, one of the oldest and most trusted databases in the world. In one account it gives you:

• The database, with tables like products and customers.
• Row Level Security, rules inside the database that decide which rows each user may see. This is how every company sees only its own data even though all companies share one database.
• Database functions, small programs inside the database that do a whole operation at once. Recording a sale means creating the invoice, reducing stock, adding money to a cash box and writing an accounting entry. A database function can do all four as one operation that either fully succeeds or fully fails.

Why not the simpler "document" database many app builders use? Accounting is made of relationships and rules. An invoice belongs to a customer, has lines pointing to products, and creates a journal entry whose debits must equal its credits. A relational database is built for exactly that, and it can refuse bad data instead of storing it.

The cost of this choice is responsibility. A database change goes live for every customer the moment it is applied. There is no preview for it.

Hosting: Cloudflare and GitHub

Our code lives on GitHub. When an update is merged, GitHub automatically runs our automated tests, builds the website and sends it to Cloudflare Pages, which serves it to customers worldwide. Merging is deploying, and that sentence should make you careful.

Our marketing website is not built with Flutter at all. It is plain, fast web pages, because a heavy app is the wrong tool for a page whose only job is to be found by search engines.

When you should choose something else

Our choices fit a business system used on desktops and phones. Choose differently if:

• Your product is mostly a website that must be found on Google. A framework built for websites, such as Next.js, serves you better.
• Your app depends heavily on one phone's hardware, such as advanced camera work or augmented reality. Building natively may justify the double work.
• Your data has no real relationships, like a simple chat or content feed.
• You will hire a development team soon. A stack your team knows deeply beats one that looks better on paper.

If you are coming from an AI app builder like Lovable or Bolt, the move is less scary than it sounds, because your old app becomes the best possible specification for the new one. Chapter 2 of the book walks through the five steps of moving.

To start the decision with your own project, give your assistant this:

Key takeaways

• Judge tools by popularity, platform reach, management, real database rules, starting cost and ownership.
• One Flutter codebase let us ship web, Android and iPhone, but separate web and mobile screens doubled every visible change.
• A relational database with security rules and all-or-nothing functions is the right home for business data.
• Code can be previewed. Database changes go live for everyone at once.
• A green check on your own computer is not proof. Only the real deployment build counts.

Frequently asked questions

Should I use Flutter or React Native for my SaaS?

Both reach web and mobile from shared code. We chose Flutter because it draws its own screens, looks identical on every device and handles right-to-left languages well. If your product is mostly a website, a web framework or React with React Native may suit you better.

Why choose Supabase instead of a document database?

Business data is full of relationships and rules: invoices, customers, products and accounting entries that must balance. Supabase is built on PostgreSQL, a relational database that can enforce those rules, refuse bad data and run several steps as one all-or-nothing operation. A document database leaves more of that to your code.

Can I preview a database change before it goes live?

Not in our setup. A website update gets its own temporary preview copy, but the database is shared and a change is live for every customer the moment it is applied. So rehearse every database change in a test that undoes itself, and look at the before-and-after numbers before running it for real.