Six steps. The software does the repetitive ones, and a person takes the last one.
This is the path every application here has taken, including the one rendering this page.
What the application is for, who uses it, what it has to keep track of and why it's worth doing. Ideas are scored and ranked so the next thing built is the next thing worth building, not the newest thing suggested.
The idea becomes a list of features, worked out in conversation with an AI assistant that already knows the idea. Each feature says what it does and what "done" means, in enough detail to build from.
Features are grouped into a version. That version is the unit that gets built, released and talked about, so there's never a question of which features are in each version.
The application's repository, database, web address and background services are created if they don't exist. Then the build runs from the version's features, and the result deploys to that application's private development site.
The development site is where it's used for real. Anything wrong with a delivered feature is filed against that feature as an amendment, so the record of what changed stays with the thing that changed.
A person releases the version and promotes it to production. The version's features close out with it. This step is deliberately not automatic.
None of this is written per application. It arrives with it.
Identity and access. Sign-in shared across the whole family of applications, with sign-out that covers all of them. Each person's role and the data they're allowed to see are decided in one place, and every application asks that same place. Teams and workspaces, where an application needs them.
A record of what happened. An audit trail, revision history on records, and a readable short code on every record, because "page 8" isn't something you can say to a colleague.
Measurement. Who used what, satisfaction surveys asked on a schedule rather than at random, AI usage and cost per application, and one dashboard across all of them.
AI access. Applications reach AI through the platform, so none of them holds an AI vendor key, and every request is counted and costed.
Agent access. Each application has its own MCP server, so an AI agent can operate it with exactly its person's permissions. There's no second set of permissions for agents that could drift out of line with the first, which is what makes this safe to turn on rather than interesting to demo.
The plumbing. Background job processing, scheduled tasks, file handling, notifications, and a shared set of design and theming choices so the applications look like they come from the same place.
Every one of these guards exists because something went wrong once, which is the only reason worth having.
Four checks on every build. Code style, a successful build, the full test suite run against the same kind of database production uses, and a check that the application actually starts in a browser rather than only compiling. That last one exists because an application once built perfectly and showed a blank screen.
Guards on every deploy. The same deploy script across the fleet, with the checks that were missing the day each of them was needed, such as creating the file-storage link so an application that accepts uploads isn't broken on arrival.
A refusal to promote a mismatch. If the development site is behind the main code line, the merge that would go to production is a combination no environment has ever run. The platform refuses rather than trying it in production.
Watching the servers. Background job handling and scheduled tasks are set up as part of provisioning rather than remembered later, and their health is on a dashboard, because a scheduler that quietly stopped looks exactly like one with nothing to do.
An application can be a web application on its own address, or a SuiteApp that lives inside NetSuite: your data, your roles, your menus, no second system to log into and no integration to maintain. That choice is made per application, before it's built, because it changes how it's built.
Most shops do one or the other. Being able to answer either way removes the objection a NetSuite customer raises first.
Describe the problem and I'll tell you what the first version would contain.
Getting started