Web applications that carry the actual work.

• Choose a web application when users need accounts, state and permissions.

  People sign in, see only their own or their role data, and change records other people depend on. That is an application, and the data model is where the build starts.

• Choose a website when the job is publishing and conversion.

  If nobody needs to sign in and no data has to persist between visits, an application is capability you will pay for and never use. Business websites or custom website development is the right route.

• Consider SaaS when the same software serves many organizations.

  Once you are selling access to multiple customer organizations rather than running it for one, tenancy, plans and billing become first-class concerns. That is multi-tenant SaaS development.

A website publishes information to visitors, and most of its value lies in being found and read. A web application does work for signed-in users: it stores state, enforces permissions and changes data. The two need different architectures, and treating an application as a website produces a login bolted onto a brochure site.

The practical test is whether anything has to be remembered about a person between visits, and whether two users should see different things. If the answer to both is no, it is a website. If yes, the data model and the permission model become the center of the build and the page structure follows them.

• Websites optimize for being found; applications optimize for being used.
• Websites serve everyone the same page; applications serve each user their own data.
• Websites publish content; applications change records and keep a history.
• Websites are measured in traffic and conversions; applications in completed work.
• Most real products are both, with a public site in front of an authenticated application.

Authentication establishes who someone is; authorization decides what they may do. Both are enforced on the server for every request. Credentials are hashed, sessions are handled server-side, and roles map to explicit rules rather than to hidden interface elements — a hidden button is not a permission.

Applications are designed with appropriate security practices, and we will not claim more than that: no system is unbreakable, and a supplier who guarantees security is telling you something untrue. What we do commit to is that access rules are explicit, checked server-side, logged where it matters, and documented so they can be reviewed rather than trusted.

By cutting the build into releases that each stand on their own. The first release covers one complete path through the process — not a fraction of every feature — so it can be used, and what is learned from real use informs the next release rather than being guessed at the start.

The failure mode this avoids is a twelve-month build that meets a specification written before anyone had used anything. Software is a set of assumptions about how people work, and the only reliable way to test those assumptions is to put a usable version in front of them early.

• Web applications
• Application frontends
• Workflow and process applications
• Application state and data modeling
• Role and permission design

Applications are discussed as if they were one thing. They are four, and knowing which layer a requirement belongs to is what makes a scope conversation productive rather than circular.

• The process becomes visible

  State lives in one place with a history attached. Questions about what is outstanding or what happened are answered by the application rather than by the person who remembers.

• Permissions are real

  Access is enforced on the server and logged, so what each role can see and do is a rule rather than an agreement — which is what makes delegation safe.

• One version of the data

  A designed data model removes the duplicate entry and the weekly reconciliation, which is usually where the actual saving is.

• The product can be found

  Marketing pages, documentation and pricing stay server-rendered and indexable while the application itself stays out of the index. Both halves get the treatment they need.

• An operations tool replacing shared spreadsheets

  Jobs, cases, stock, applications or approvals moving through states, with several people working the same queue and needing to see the same truth.

• A workflow with approvals and roles

  Work that has to be submitted, reviewed and approved by different people, where who did what and when is part of the requirement.

• A prototype that has to become a product

  Something validated in a spreadsheet or a no-code tool that now needs real accounts, real permissions and data integrity to carry paying users.

• TypeScript end to end, so the shape of the data is enforced across the interface, the server and the database access layer.
• A relational data model by default, because most business processes are relationships and enforcing them in the database is cheaper than enforcing them in code.
• Permission checks on the server for every request; hiding a button is presentation, not security.
• Designed with appropriate security practices — hashed credentials, server-side session handling, parameterized queries, secrets in environment configuration — and no claim that any system is unbreakable.
• Releases sliced so the first useful version ships early, rather than everything arriving at once at the end.
• Audit trails on the actions that matter, because in an application with roles, who changed what is part of the data.