MVP backend: when static data is enough and when you need an API

Static data is enough for an MVP when a developer can maintain a small, mostly public dataset and updates can wait for a deployment or manual refresh. You need an API backend when people must edit shared data independently, access needs permissions, or several clients need the same current records. The choice depends on how the product works today, rather than how large you hope it becomes.

Start with the editing process

A JSON file, hard-coded content, or a spreadsheet can be a sensible first source. A landing page with five examples does not need a database just because it might become a marketplace. A developer can review changes alongside the frontend, and a spreadsheet lets someone maintain rows without editing source code.

Ask what happens after someone changes a value. Does the site rebuild? Does someone copy spreadsheet rows into JSON? Is a manual refresh acceptable? A spreadsheet may simplify editing while still leaving publication as a manual step. That can be enough while you are testing whether anyone wants the product.

The boundary changes when a customer submits a record, an editor needs an immediate update, or two apps must agree on the latest value. Those are shared data requirements, not merely more content.

Static data or an API?

Decision	Static data is enough	An API backend fits better
Who edits data	Developer edits files, or one person maintains a sheet	Editors and users need independent access
How often it changes	Occasional updates can wait for publication	Changes must reach clients without a code release
Auth and roles	Data is public; editing happens outside the app	Reads and writes need enforced permissions
Multiple clients	One site consumes a controlled snapshot	Web, mobile, or scripts share current records
Search and filter	A small public dataset can be filtered locally	Clients need filtered, sorted, paginated reads
Cost	Little infrastructure, with manual work per update	Server operation and setup, with less manual copying

Use the table to identify today’s constraint. A hundred public entries might work perfectly in a file. Ten private customer records already need a proper access boundary. Record count alone does not decide the architecture.

The cost of building too early

A custom backend means more than returning JSON. You must design storage, validate writes, enforce permissions, handle credentials, and keep the service running. Building those pieces before the product’s data model settles creates work you may discard after the next customer conversation.

Static data has a later cost too. Moving it means cleaning inconsistent values, defining fields, replacing file reads with requests, and checking which records should be public. Copies scattered across components make that harder. Keep one source, consistent identifiers, and one place where the frontend loads data. Those small choices make migration easier without building a speculative backend.

An API from day one without writing one

Kanesh offers another starting point: use an existing backend and spend your time on the product. It is free to self-host for one workspace, but hosting and maintenance remain your responsibility. Kanesh is new and at its first stable release, so test it against your requirements before relying on it.

Create collections through Settings → Data model → Create collection in Studio. Alternatively, Codex or Claude Code can create collections and records through the REST API using an authorized token. MCP only reads schemas and records; it cannot perform those writes. Each collection becomes available through REST and GraphQL immediately.

Start with the Docker image and SQLite on a small server. SQLite is the default and needs no separate database service. Follow getting started, then use the database guide to understand PostgreSQL or MySQL configuration when your deployment needs it. Moving existing data later is a migration you must plan and verify; changing a connection setting alone does not transfer it.

The blog use case gives a concrete content model, and the SvelteKit and Next.js guide shows frontend integration. For another option, read the PocketBase comparison. Realtime, OAuth, workflows, and functions are on the roadmap, so do not include them as available features in your MVP scope.

Signs you have outgrown static data

• Editors wait for a developer to publish ordinary changes.
• Users need to create or update persistent records.
• Different roles need different read or write permissions.
• Several clients maintain conflicting copies of the same data.
• Local filtering requires downloading data clients should not receive.
• Manual copying now causes recurring mistakes.

FAQ

Does every MVP need a backend?

No. A public prototype with occasional content changes can use files or a spreadsheet. Add a backend when shared writes, permissions, or publication needs justify operating one.

Is migrating later always cheaper?

No. It saves early development effort, but inconsistent data and duplicated loading logic can make migration expensive. Keep a clear source of truth and revisit the choice when manual work becomes routine.

Can Kanesh replace all custom server code?

No. It supplies collection APIs and access control, but your product may still need its own business logic. Check Kanesh’s current capabilities against your requirements before choosing it.