Tell us what the software has to do. We build it.
Describe the business you run and the product your customers need. We scope it, build it and launch it on SynaptaGrid — using shared services for sign-in, customer accounts, data separation, billing and audit. New product, an application you already run, or the integrations between them. Your application and its source code are yours; the platform it runs on stays ours, provided as a service.
Start from nothing, from what you have, or from what it has to connect to
Most engagements are one of these three. Several are two of them, and the boundary is drawn in the scope rather than in the invoice.
Build a new product
You have a requirement and no software yet.
We design and build the application against a written scope, and it launches on infrastructure we provision and operate.
- Your data model, screens, rules and reports
- Sign-in, customer accounts, billing and audit supplied by the platform rather than built in the project
- A product your customers sign into on your own domain
Bring an application you already have
The software works. It cannot be sold to enterprise buyers yet.
We integrate what you already run with the platform, so the parts that block a security review stop being your problem to build.
- Company sign-in, provisioning and multi-factor authentication added to your existing login
- Customer separation, roles and permissions applied to data you already store
- Audit history, plans, invoices and usage limits connected to the application, with the changes agreed in the scope
Connect the systems around it
The product has to talk to the rest of the business.
Integration work as its own engagement, whether or not we built the application at either end of it.
- Accounting, CRM, ERP, logistics, laboratory and industry systems
- Scheduled imports and exports, file drops, spreadsheets and legacy formats
- APIs and webhooks for your customers to build against, with delivery retries and a record of failed deliveries
Founder with a spec and funding but no engineering team? See how a founder build works →
The parts every B2B product needs are supplied. The project builds the rest.
Sign-in, customer organizations, roles, permissions, plans, invoices, audit history, tenant provisioning and monitoring appear in every business application. On SynaptaGrid they are platform services we operate, so they are configured and connected rather than built for each project.
We built and operate this foundation for our own products, and the same services run under every application we deliver.
The project is the part that is actually yours — your data model, your screens, your rules, your integrations. It is the part nobody else can specify for you, and the written scope says exactly what it includes.
See the full comparison of what your team would otherwise own →
Five steps, and you can stop after any of them
No discovery phase that produces a slide deck. The first thing you see is a scope you can argue with; the second is software you can use.
You describe the requirement
In a call, an email, or a document you already have. Enough to say who uses it, what they do with it and what the business needs out of it. There is no template to fill in and no cost to this conversation.
We write the scope back to you
The data model, the screens, the rules, the integrations, and what is deliberately left out of the first release. You approve it before anything is built. If we think you are asking for the wrong thing, this is where we say so.
You use it while it is being built
A working environment with your own accounts from the first milestone. Every milestone is something you can open and click, not a status report. Requirements that turn out to be wrong get found here rather than after launch.
Launch
Your customers, your domain, your branding. We operate the platform underneath it — identity, tenancy, billing, audit, monitoring — and support that layer during the hours written into your contract.
You can take it over whenever you want
Your developers can take over application development using the source and documentation. We agree export and transition assistance in the contract and review the services the application needs to keep running.
What we build for you, and what is already there
The left column is the project. The right column is the platform you subscribe to, and it is not rebuilt for each customer.
Built for you
Scoped, quoted and delivered as your project.
- Your data model and the records that make the product worth using
- The screens your users actually work in, every day
- Business rules, approvals, calculations and states
- Documents, imports, exports and the reports someone needs on Monday
- Integrations with the systems you already run
- Whatever your industry requires that no off-the-shelf product covers
Already there
Operated by us, shared across every product on the platform.
- Sign-in, multi-factor authentication and company logins for enterprise customers
- Customer organizations, teams, roles and permissions
- Plans, subscriptions, invoices and usage limits
- A customer portal and an operator console
- An append-only record of who changed what
- Database-per-instance application data, and dedicated infrastructure where a plan calls for it
- Monitoring, tracing and alerting connected to the deployment
Your application, source and handover
The running product
Deployed, with your customers on it, on infrastructure we provision and operate.
The source code
In a repository you own, from the first commit. Ownership and licence terms are written into the contract.
Written documentation
The data model, the workflows and every integration, described well enough for a developer who was not on the project.
Automated tests
Covering the behaviour the product is paid for, running on every change so a later edit cannot quietly break it.
An operator console
Your team manages customers, plans, access and settings without opening a support ticket with us.
A way out
Your data exported in a documented format. The contract defines export timing and transition assistance; the Trust Center describes what is available.
Trust Center: data ownership, export and service continuity →
When this is the right call, and when it is not
Both lists are short. We would rather lose a project in the first conversation than deliver one nobody needed.
Bring us this
- Your business runs on a process no product on the market matches, and spreadsheets and email are currently holding it together.
- You sell to companies, and every customer needs their own accounts, their own data and their own settings.
- You have a product to build and no platform team — and no intention of hiring one to build foundations twice.
- You already have an application that works, but cannot sell it to enterprise buyers until it has identity federation, audit evidence and data isolation.
We will talk you out of this
- An existing product already does this well. We would rather tell you that in the first conversation than bill you to rediscover it.
- The requirement is still a hypothesis. Start with a short discovery — building against a guess is the expensive way to test one.
- A small internal tool with no customer accounts and no tenants. The platform is more than that needs, and you should not pay for it.
You own the application. You own the data.
Agree application ownership, data export and transition assistance in the contract. Review the Platform services your application depends on and what a future handover would involve.
Your application’s code is yours
In your repository from the first commit. The contract sets the licence and ownership terms for the application code. The platform it runs on is a service you subscribe to, and its code stays ours.
The data is yours
Exportable in documented, standard formats. The contract defines export timing, transition assistance and deletion after the service ends.
Your team can take over
Your developers get the same SDK access and documentation we build with, plus the source and the project documentation. Transition help is agreed in the contract.
Scoped and priced before work starts
Two separate things, so you can see which is which.
The build
Quoted against the written scope and delivered in milestones, each one something you can use. Scope changes are re-quoted in writing before they are built, so the number you were given does not quietly move.
The platform
A separate subscription, and what you continue to pay after launch. It reflects tenant scale, regions, isolation and operating coverage rather than the size of the build.
See the commercial model →The team is small on purpose. The architect who scopes your project is one of the people who writes it, so nothing is lost between the conversation and the code. About the team →
Send us the requirement in your own words
A paragraph is enough to start. You will get a written scope back, or an honest answer that we are not the right people for it.