SaaS is a dormitory for companies

SaaS gives each company a furnished room in a building designed for thousands of tenants. Its speed and its limits come from the same choice.

A dormitory is useful. You can move in quickly. The room already has a bed, a desk, electricity, internet, cleaning, and somebody responsible for repairs. The upfront cost is low because the building, staff, and common services are shared.

The arrangement works because residents accept the same architecture. Every room follows a small set of floor plans. The management sets the access policy, maintenance schedule, permitted alterations, and price. You can bring your own possessions and arrange the furniture. You can't remove a wall because your routine would work better with the room next door.

SaaS has the same economics. One product serves thousands of companies. Each customer gets an account, their own data, standard workflows, settings, support, and continuous maintenance. The vendor can ship quickly and charge less because every customer runs on the same underlying product.

That is the advantage. It is also the boundary.

The analogy is about control

Sharing a SaaS product doesn't mean other companies can see your records. A competent SaaS vendor isolates each customer's data and permissions. The dormitory analogy concerns the building: the product architecture, available features, commercial terms, and roadmap are shared.

Your company can configure the options the vendor exposes. The vendor decides which options exist.

When the provider changes a feature, retires an integration, raises its price, or limits an API, every tenant has to respond. A large customer may influence the roadmap, but it still cannot change the building directly.

Settings rearrange the furniture

Settings are useful. A company can create fields in Salesforce, configure an approval in an expense tool, add a view in a project manager, and connect an automation through Zapier.

These changes rearrange the furniture. They help the standard room fit better.

The limit appears when the organisation needs a rule the product never anticipated. A distributor wants credit approval to depend on live inventory exposure across three warehouses. A clinic group wants scheduling to treat one class of patient differently based on clinical and insurance evidence. A services company wants revenue recognition tied to the actual delivery record rather than a generic project status.

The company then has three options: change how it works to fit the SaaS, enforce the real rule manually, or build software that carries the rule properly. The second option is how people become the integration layer. The first is how differentiated operations become generic.

Owned code changes the floor plan.

Dormitories are often right at the beginning

A small team should rarely build its own email, payroll, calendar, video calling, or accounting ledger. Shared products solve these standard needs well. They let the company begin operating before it has the money or attention to build internal systems.

The dormitory can also be the right permanent home for work that should remain standard. A company gains little from inventing its own meeting scheduler or password manager.

The pressure to move appears where the operation becomes specific. Growth introduces its own pricing rules, approval paths, service promises, risk controls, and management questions. The settings that were adequate for ten people become a maze of workarounds at one hundred.

Outgrowing SaaS in one part of the operation is evidence that the company has developed a way of working worth preserving.

A company does not need to own every appliance

Moving into your own home doesn't require generating your own electricity, drilling for water, manufacturing a refrigerator, or building an internet network. Ownership means controlling the space and choosing the services connected to it.

The same principle applies to internal software. A company can continue using Salesforce, QuickBooks, Slack, Google Workspace, Stripe, and frontier AI models. The owned operating layer connects them, decides which system is authoritative, carries the company's workflows, and gives people a coherent interface.

We should keep a SaaS product where it performs a standard function well. We should integrate it rather than rebuild it for pride. The company needs to own the context, rules, permissions, and interfaces that make its operation distinct.

Asynchronous rules expose the boundary

The two speeds of organisational change gives us a precise test. Live operational changes happen through the UI. Durable changes to how the organisation will work belong in code.

SaaS allows the asynchronous changes already represented in its settings. The company can add a field, change a permitted threshold, or select a workflow template. A new rule outside those settings waits on the vendor, gets enforced by people, or becomes owned code.

Every repeated workaround is a sign that the company has tried to renovate a dorm room. A spreadsheet beside the CRM, an approval living in Slack, or a person re-entering data between portals is the organisation compensating for architecture it cannot change.

Ownership protects the ability to evolve

The strategic reason to own internal software is the freedom to keep changing the organisation.

Company-owned code can express a rule the leadership decides today, connect a vendor chosen next year, and preserve the operating history accumulated along the way. The client controls when a change ships, how it is tested, who approves it, and what happens if a provider is replaced.

Ownership also makes the exit real. Data exports alone are insufficient when the business logic remains trapped in vendor configuration. The workflows, agent instructions, permissions, evaluation rules, and audit history need to remain usable outside any one SaaS account.

How this guides Aiwah

The dormitory analogy gives us a practical doctrine:

• Use SaaS for standard capabilities where shared architecture is an advantage.
• Keep the tools a client already uses when they do their job well.
• Identify the workarounds that reveal where the organisation has outgrown vendor settings.
• Build the company's differentiated workflows, context, permissions, and interfaces in an owned layer.
• Connect rented services through boundaries the company controls.
• Encode every recurring asynchronous rule that falls outside SaaS settings as company-owned software.

SaaS gives a company somewhere ready to operate. Owned internal software gives it the freedom to shape the operation around what makes the business different. A growing company will usually need both.