How this works

Why deployment takes days instead of months

Every business application needs the same things underneath it. User accounts and roles. Permissions. Background jobs. Audit trails. Import and export. Email delivery. Reporting. That layer is roughly the same whether you are tracking deals or tracking crews, and building it from a blank page is where most of the calendar goes on a custom project.

We built that layer once, years ago, and it has been running in production ever since. Every application we deploy starts from it. That is the entire reason a deployment is a matter of days: we are not writing the boring 80%, we are fitting the 20% that is actually about your business.

The foundation itself is not for sale and does not appear on the price list. It is not a product, it is the reason the products are cheap to deliver.

Where your application actually lives

A standard engagement runs on a dedicated virtual server that serves your deployment and nothing else. One client, one server, one database. There is no shared multi-tenant database, and that is what makes the ownership claim true rather than a marketing line.

It runs under your own registered domain, not a subdomain of ours. Your people go to an address with your company name in it, and the certificate is issued to you. This matters more than it sounds like it does: it is the difference between visiting your own building and visiting a floor of ours.

Whose cloud account

We start in ours. That is not the pitch, so here is the honest reasoning: a first deployment into a client's own AWS or Azure account turns a two-day job into a three-week job of access requests, billing approvals, and permission boundaries, and it happens before you have any reason to trust us.

So the standard engagement starts on a dedicated server in the devInstance account. Migration into your own AWS or Azure account is a defined milestone, and it is included at no charge at ninety days if you want it. After that, the hosting line item on your invoice disappears, because you are paying Amazon or Microsoft directly instead of paying us to pay them.

On-premises deployment is available for businesses that need it. It costs more to set up and sits one service tier higher, because supporting hardware we cannot see is genuinely harder.

What you are actually paying for every month

The main objection to owning your own software is that you now own its problems. This is a fair objection, and the service plan is the answer to it. It is not a support inbox. It is the operations team you would otherwise have to hire.

• Updates. A release every month. Security patches, framework updates, fixes, and new capability across the application.
• Security patching. Operating system, runtime, and database, on the same monthly cadence, plus out-of-band patching for anything urgent.
• Backups with point-in-time recovery. Continuous, not a nightly snapshot. If something goes wrong at 2:40pm we can restore to 2:39pm rather than to last midnight.
• Restore drills. Scheduled and documented. A backup nobody has ever restored is not a backup.
• Monitoring. Uptime, error rates, and resource use, watched by us rather than reported by you.
• Hosting. Server, database, storage, and TLS certificates, itemized on the invoice.
• Email delivery. Transactional email from your own domain, properly authenticated, with a monthly message allowance.
• Support. Response times and included hours vary by tier. See the pricing page.

Included hours cover small changes and support overflow. New feature development is customization work and is quoted separately. We put the line in writing so nobody has to argue about it later.

What you own, and what happens if you leave

While we are working together

• Your data and your database are yours outright, at every moment, with no clause anywhere that says otherwise.
• You get API and integration documentation with the initial build, so you can hire any developer to build against it without involving us.
• Your deployment runs under your domain and, after migration, in your own cloud account.

The first year

The initial build carries a one-year warranty covering defects in the delivered code and security updates. A defect is the application not doing what we agreed it would do. A change request is you wanting it to do something different. That distinction is defined in the contract in writing before anything is signed, because leaving it vague is how these relationships go bad.

If you cancel

• You keep the running deployment and the compiled application under a perpetual license. Nothing is deactivated, throttled, or switched off.
• You keep the database and every record in it.
• Updates, support, monitoring, and hosting stop, except warranty items still inside the one-year window.
• If we were hosting you, we hand over the deployment or help you move it. That is billable at the hourly rate, and it is a job of days.

What you cannot do without buying more

Two limits, both stated plainly rather than buried.

Changing the source code yourself requires the source license, a one-time fee listed on the pricing page. It requires an active service plan, and it does not include the right to redistribute the code.

Reselling the application as a service to other companies is not permitted by default. If that is your actual business model, tell us and we will negotiate a partner arrangement. We would rather structure it properly than have you discover the restriction after you have sold something.

Where this is the wrong answer

Being specific about the fit is faster than a sales call for both of us.

• You want to try it for $50 a month. This is not that. The deployment fee is real and the commitment is twelve months. If you are still deciding whether you need software at all, buy something monthly and come back when it stops fitting.
• You need a specialized vertical product. If a mature tool exists for exactly your industry and you use most of what it does, use it. This model wins where the fit is bad, not where it is good.
• You have no internal owner. Someone at your company has to be able to say what the process is and make decisions about it. Without that person the fitting phase has nothing to work with.
• You want to be a reseller. Different conversation and different agreement. Start it with us before you build a business on it.

Questions we get asked

How long does a deployment actually take?

Days for the deployment itself. The fitting work that follows depends on how much has to change, and is typically two to six weeks. We give you a date before you sign, not after.

What if I want changes after go-live?

That is customization, billed hourly at the rate set by your service plan, with prepaid blocks discounted. Small changes come out of your included plan hours.

Do you charge per user?

No. Nothing on the price list is per seat. Your user count is your business.

Can I see the source code?

Under the source license, yes. Without it, you have the running application, the database, and the API documentation.

What happens if devInstance goes away?

You keep a running deployment, your database, your documentation, and a perpetual license. Your data is in PostgreSQL, which any competent developer can work with. This is a materially better position than the one you are in with a SaaS vendor that shuts down.

Who owns the cloud account?

We do at the start, you do after migration, which is a defined milestone and free at ninety days. On-premises is also available.

What is your uptime commitment?

Stated in the service agreement and varies by tier. AI features are excluded from it, because they depend on third-party model providers we do not control.