App, database, login.
One build.
A custom CMS, a web application or an Expo mobile app on Supabase: a Postgres database, user accounts, file storage and live updates. Designed, built and deployed by the same people, in accounts you own.
Front end. Back end. One scope.
Screens, tables, roles and integrations are listed in the written scope before a line of code is written.
One build. From €1,799.
The starting scope covers front end and back end together: up to 6 screens, 6 tables, login, 2 roles and one payment or email integration, with two rounds of design revisions. Bigger scope is quoted in writing. Supabase and hosting bill you directly, and the scope states what they will cost to run.
Data first. Then screens.
A typical plan. Tables, roles and integrations move it. Work beyond the starting package is scoped and dated separately.
Schema design
Data modelled, relationships drawn and security policies planned. Screens and user flows agreed in writing.
Backend setup
Supabase project created in your organisation. Tables, row-level security, login providers and storage configured.
Frontend
React screens built on the live schema, with real-time features, on preview URLs you can open any day.
Security review and launch
Every policy tested as every role, edge cases worked through, then production and handover.
The data stays yours.
In standard Postgres, exportable on any day.
Standard Postgres
Supabase is open source and runs plain Postgres. The database can be exported and moved to any Postgres host.
Security at the database
Row-level security sits on every table. A mistake in the frontend cannot show one user another user's rows.
Every schema change on record
Each change to the database is a migration file in your repository, with a date and a reason.
Daily backups
Supabase's paid plans back the database up every day, restorable from the dashboard.
Scope in writing
Screens, tables, roles and integrations are listed before the build. A change is priced before it is made.
Bugs fixed
Anything in the delivered scope that does not work as agreed is fixed as part of the build.
Apps with users. Not pages.
If the second list sounds like you, another page here fits better.
This build fits
- 01The first version of a SaaS product
Accounts, teams, roles and billing, on Postgres from the first day.
- 02A loyalty, rewards or subscription app
Customer accounts and balances next to a D2C store.
- 03A community platform
Posts, replies and notifications that appear as they happen.
- 04An internal business tool
Inventory, CRM or operations, with a role for each person.
- 05A custom CMS
An editor built around your content, where an off-the-shelf CMS does not fit.
- 06A mobile app in Expo
One React Native codebase for iPhone and Android, on the same Supabase backend.
Look at another page first
- 01It is a website of pages to read
Website Development, from €179 for a single page and €899 for up to 10 pages.
- 02You only need an installable web app
A progressive web app is €599 per application.
- 03It is a shop
Shopify already holds the catalogue, the orders and the checkout.
Tested as each role. Then launched.
Each one is checked before launch, and the evidence comes with the repository.
Row-level security on every table
No table is readable without a policy. The list of policies is in the handover.
Policies tested as each role
Before launch, every role signs in and tries to read and write what it should not.
No service key in the browser
The frontend holds only the public key. Privileged work runs in Edge Functions.
Types from the schema
TypeScript types are generated from the database, so a renamed column fails the build.
Migrations, not dashboard edits
The production schema matches the migration files in Git.
Keyboard and screen reader
Menus, dialogs, tables and forms work without a mouse, with labels and visible focus.
What founders ask about the backend.
More in Web & Apps.
App, database, login.
One call.
Thirty minutes on what the app has to do. A written scope after it, with the running costs.