One table, typed columns, a CRUD UI, and a form to add rows is standard, bounded work — multiple synchronized views over the same data, kept live as you edit any of them, is where the real depth is.
Borderline
Effort: a weekendRunning cost: $0/mo to start
Why CanICodeThis says Borderline
One table, typed columns, a CRUD UI, and a form to add rows: standard, bounded work
Filtering and sorting a single view is a query builder, not a research problem
For a genuinely narrow personal database — a single table doing one job — this is squarely a weekend project
The parts that'll cause problems
Multiple synchronized views (grid/calendar/kanban/gallery) over the same data, kept live as you edit any of them, is real engineering depth
Relational links between tables with rollups and lookups is a small query-planning problem, not a checkbox feature
An automation builder and API access at scale are a second product layered on top
How I'd build this
frontend
Next.js
database
Supabase
hosting
Vercel
MVP scope
One table with typed columns (text, number, checkbox, select)
A CRUD UI with a form to add rows
Filtering and sorting on the main view
Postpone to v2
Multiple synchronized views (kanban, calendar) over the same data
Relational links between tables
An automation builder
What it actually costs to build
AI agent — with a subscription (Claude Pro/Max, Cursor, etc.)
$0 marginal
AI agent — pay-per-use API, no subscription
$43–$86 one-time
Hosting, once it's running
$0/mo (free tier)
Domain name, if you want your own
~$12/yr
Existing tools solving a similar problem typically run $24–$24/mo — see how they compare below.
The build prompt
Build me a single-table database tool, not a general spreadsheet-database platform:
1. One table with typed columns (text, number, checkbox, select) — a schema and a CRUD UI.
2. A form to add rows inline.
3. Filtering and sorting on the main view — a query builder over one table.
That's a real, complete single-table database for a narrow personal use. Out of scope: multiple synchronized views (kanban, calendar) over the same data staying live as you edit any of them, real engineering depth, not four separate UIs, and relational links between tables with rollups, a small query-planning problem most single-table builds don't need to solve.
