SaaS development

Build a product that can keep changing after launch.

A SaaS product is not a feature list with a login in front of it. It is software offered as an ongoing service: accounts, permissions, a first version someone can actually use, and a way to operate and change it afterwards. PrimeLabs can reach that first useful version quickly. The architecture still has to survive the second release.

Software delivered as a service

People come back. The product holds their work between visits. Common pieces are accounts, an organisation or workspace where more than one person shares that work, permissions, settings, a subscription or another entitlement, updates that reach everyone, and a way for someone to support the account. A product for a single user still needs an account and a release process. It may not need organisations, plans, or a billing provider. Naming the pieces is not a claim that every product includes all of them.

A first release should be small, and still real

A proof of concept answers whether an approach can work. A prototype shows a path. An MVP is a name people use for the smallest thing a user might try. PrimeLabs treats the first production release as something else: small, coherent, safe, and usable by the people it is for. It is not a disposable structure that has to be thrown away to go further.

Speed matters. The first useful outcome is named before the rest of the catalogue. What does not belong in that release stays out. The accounts, the permission check and the release path are in it, because those are what make the next change possible. AI-assisted engineering shortens the cycle of drafting and review. It does not decide the scope. That practice is AI application development.

The boundary has to be explicit

Some products are one person and their data. Some are an organisation with many users. Some allow a person to act for more than one organisation, or a delegated user who can see a slice and not the rest. Product admins are a different role again: they operate the service, they are not just another user inside a customer’s workspace.

Whatever the model, the boundary is named. A query for jobs is a query for this workspace’s jobs. A file, a report and a webhook follow the same rule. Authentication answers who the person is. Authorisation answers what they may see or do: a role, the organisation they are in, and the specific record. An admin role is not a reason to skip the object check.

Settings are part of the product

A workspace often needs its own switches: which modules are on, how a job moves, who is notified, what the account prefers. A plan may turn a capability on or off. That can be a small set of rules in the application. It does not require a separate feature-flag platform unless the product has earned that complexity.

Where money is part of the offer, the same honesty applies. Plans, a trial, a seat or usage limit, a grace period, and what happens when a subscription ends are product decisions. The billing provider is an integration, not the product. It is not assumed to be any particular vendor. How that exchange is built is API integration, and only where that provider’s API, permissions and data model allow it.

Someone has to operate the accounts

A production product needs a surface that is not the customer’s screen: find an account, see its users and plan, read a workflow that failed, see what changed, and leave a note. The FieldFlow admin view is that idea. It is often an internal business application beside the product, and the figures on it are dashboards and reporting when the question is usage, health, or which tenants need attention.

Some products begin as that internal tool and later open a customer-facing version. Some customer-facing products quietly require the internal tool before they are safe to run. A customer portal is the other shape: a signed-in view of a relationship the organisation already has. A SaaS product is itself the thing being offered. The screens can look alike. The responsibility is different. A portal does not have to acquire the next customer. A product does, and someone has to keep it running after they arrive.

Frame, build, operate, evolve

Launch is the start of the service. Frame names the user, the job, and the first outcome. Build ships that slice. Operate watches errors, failed work, and the accounts that are stuck. Evolve uses what people actually did, and what they asked for, to choose the next slice. Usage does not write the next feature by itself. A person still decides.

Identity, billing, accounting, a CRM, email, payments, storage and other product APIs are ordinary neighbours. Each one is a separate feasibility question. Product analytics and the operator’s view of tenants often live in the same platform, with different permissions.

Isolation is the security requirement

Sessions end. Secrets stay on the server. A support role can see less than an owner, and an owner of one workspace can see nothing of the next. Files are checked the same way as rows. Admin actions are recorded. Where a public endpoint can be called in a burst, it is limited. The web application around the product is what enforces that. Operators also need a plain view of errors, failed jobs, request health, background work, account problems, usage, and which version is live. That is part of running the product, not a separate infrastructure pitch.

A model can sit inside the product. It is not the product.

Search in the user’s own words, a summary, help during onboarding, reading a document, a suggestion, a draft reply for support, or an explanation of an unusual spike: those are features when they remove work. They use the records the person is allowed to see. They do not replace the permission check, the entitlement, or the count. Many products do not need any of this in the first release. When the feature is retrieval over a body of sources, with the passage left visible, that pattern is AI knowledge systems.

What has to be known before the build

Who the user is. The problem they already have. The one workflow the first release must finish. The outcome that makes it useful. The roles. Whether there is an organisation boundary. The integrations that are actually required. The commercial model, if there is one. How sensitive the data is. Who will operate the product after launch. A hypothesis with none of those answers is a reason to test more cheaply, not a reason to start the product.

Start from the first job the product must finish

A useful note names the user, that job, who else is in the account, and what must be true before anyone is invited. There is no account on this website.

Discuss a product

Straight answers