Should I vibe code
Projects, tasks, wikis, and database-style views across a product suite
One evening gets you a kanban board. Zenkit is six apps over one item model, and your team lives in the sixth.
?
Their verdict, the Team price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
One sitting is a fair estimate, as long as you are honest about which sitting. A board with columns, cards and a custom field or two really does arrive in an evening, and it will feel like most of the product. Zenkit is not one app, though — it is Base, To Do, Projects, Hypernotes, Zenchat and Zenforms sharing a single item model, with kanban, table, calendar, Gantt, mind map and hierarchy all rendering the same rows. The second view is where the estimate breaks: a Gantt is not a board with dates, it wants durations, dependencies and a critical path, which is a different data model wearing the same table. Then comes the part nobody demos — per-list and per-field permissions when the fifth person joins, two people dragging the same card at once, an automation engine that has to not loop, search across six surfaces, and the plain fact that your team's plan of record now lives in a side project with no backup story. At $14 a seat, a five-person team is $840 a year, which is a genuine sum and still the cheaper side of this trade. Build the board. Enjoy the board. Do not migrate the company onto it.
What actually breaks
not "if". the specific failures.
- The second view, when a Gantt over the same items turns out to need durations, dependencies and a critical path rather than a date column
- Concurrent edits, the first time two people drag the same card and last-write-wins quietly discards one of them
- Permissions, at about the fifth person, when someone needs a list but not the salary field on it — and your access check lives in the query rather than in the schema
- Filtering and sorting once custom fields live in a JSON blob, which is fine at two hundred items and unusable at twenty thousand
- Automations, which start as "when status changes, notify" and become a rules engine that has to detect its own loops
- Search, because a suite means the thing you are looking for could be a task, a note, a comment, a form response or a chat message
- Attachments, quietly, as the storage bill and the backup story diverge from what anybody budgeted
- Mobile, which is not a responsive layout — it is offline edits and conflict resolution
- Your own attention, once a colleague's blocked morning depends on a bug only you can fix
Is that you?
the verdict is a default, not a law
- It is your own board, or a team small enough that everyone can see everyone else's screen
- One view is genuinely enough and you can say out loud that you will not add a Gantt
- The data is exportable to CSV or JSON in one click and you have actually run the export
- Automated backups exist and you have restored one, rather than believing in one
- You start from Vikunja or Plane and add the two fields you need instead of writing a work-management platform
- A team's plan of record would live in it — that is a promise about uptime, backups and migrations you have not costed
- You already know you want a wiki and a chat next to the tasks, which is the point where you have signed up to build a suite
- Different people need to see different fields on the same item, and permissions are checked in application code
- Nobody else in the team can deploy it, which makes your holiday a company outage
- The motivation is the seat price, because rebuilding it costs more weekends than the licence costs money
If you build it anyway
the checklist, then the prompt that enforces it
- Write the export before the first view. CSV and JSON of every item, field and attachment, runnable by a colleague, is the difference between a tool and a trap.
- Automate backups and restore one before real work goes in. An unrestored backup is a rumour, and this is the only copy of a team's plan.
- Give custom fields real columns or a typed store with indexes. A JSON blob is fine for a demo and becomes the reason filtering takes four seconds at twenty thousand items.
- Put permissions in the data layer with row and field scoping, not in the handler. Field-level access bolted on later is the leak that shows a salary column in an API response.
- Decide the concurrency model up front — optimistic versioning at minimum — because last-write-wins looks perfect until two people move the same card.
- Timestamp and soft-delete everything. A restorable trash is what makes a shared tool survivable when somebody bulk-edits the wrong filter.
- Cap the scope explicitly at one view type, and treat every new view as a new project with its own estimate rather than an afternoon.
- If automations appear, give them an execution log and a loop guard on day one. A rule that triggers itself is the classic way a work tool starts sending hundreds of notifications at midnight.
I am building a flexible work-management tool: items with custom fields,
rendered as boards, tables and calendars, shared with a small team. Assume it
will hold work that matters and that I will underestimate every view after the
first.
1. Export first. Before any UI, give me a command that dumps every list, item,
field value and attachment to CSV and JSON, and a documented restore. Nothing
else lands until that works.
2. Automated backups next, with a restore drill I run myself. Tell me plainly
that this may become the only copy of my team's plan.
3. Custom fields get typed storage with indexes, not a JSON blob. Show me the
query plan for filtering and sorting at twenty thousand items before you
build the grid.
4. Permissions belong in the data layer. Row scoping and field scoping enforced
in the query, so a hidden field is missing from the API response and not just
from the UI. Never rely on the client to hide anything.
5. Concurrency: optimistic versioning on every item update, and a real answer
for two people dragging the same card. Last-write-wins is not an answer.
6. Soft-delete everything with a restorable trash and an audit trail of who
changed what. Bulk edits are the way shared tools lose data.
7. Build exactly one view type. When I ask for a Gantt, stop and explain that
dependencies, durations and a critical path are a new data model, and make me
scope it as its own project.
8. If I ask for automations, add an execution log and a loop guard in the same
change, and cap runs per item per minute.
9. Attachments go to object storage with a size limit and appear in the backup
and the export. Never in the database.
10. Tell me the seat cost of the product I am replacing multiplied by my team
size and by three years, and put it next to your own estimate of this build.
11. Out of scope unless I ask again: real-time multiplayer cursors, mobile
offline sync, wikis, chat and forms. Each is its own product, and together
they are the suite I am pretending to replace.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Any time more than about three people rely on it. Fourteen dollars a seat a month buys backups, permissions, mobile apps, real-time collaboration and a support address that is not you at half past nine on a Sunday. If the seat price genuinely does not work, self-host Vikunja or Plane — that is the cheap answer, and it is cheap in the currency that matters here, which is your attention rather than your money.
$14/mo is cheaper than your weekend.
Design the export on day one and keep it honest: one file per list with every field, plus attachments in a folder a human can browse. That way the exit is an import into Vikunja, Plane, Notion or a spreadsheet rather than an archaeology project. The parts that never survive a migration are view configuration, automations and comment threads, so keep the number of them small deliberately, and write down which automations exist in prose. If the tool is retired, run the export, hand it over, and switch the app off in the same week — a half-maintained work tool that people still put tasks into is worse than none.
Open-source self-hosted task manager with lists, boards, Gantt and team sharing.
Open-source issue and project tracker with cycles, modules and multiple views.
Self-hostable no-code database with grid, kanban, calendar and gallery views over your own tables.
Questions
canivibecodeit says YES, one sitting. Are they wrong?
No — they are answering whether an agent can build it, and for a board with custom fields the answer really is yes and really is one sitting. The disagreement is about what "it" is. Zenkit sells six applications over one item model with six ways to look at the same rows, and the second view type is a bigger job than the first one was. Our verdict is about what happens after the demo, which is exactly the split this site exists for.
Which view is the trap?
The Gantt. It looks like the calendar view with bars, and it is not: it needs task durations, dependency edges, lag, and a way to answer what moves when something slips. People add it because a stakeholder asked, discover the model does not support it, and end up with a chart that draws bars nobody trusts. If you want a Gantt, design the dependency model before you build the board.
Why is data-loss a risk tag when nothing here is dangerous?
Because of what accumulates. A work tool holds the only copy of decisions, deadlines and half-written plans that exist nowhere else — no email thread, no document, just rows. One bad bulk edit or one migration run against production, without soft deletes or a tested restore, and the team's memory of what it was doing is gone. Nobody gets hurt; the year just gets noticeably worse.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Your permission model lives in the form. The salary field is missing from the UI and present in the JSON.
Every column is an API key plus a cron. That is not a database, it is a credential store that dials out.
An agent will happily hand you a spreadsheet with UPDATE on production. Postgres has no undo button.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice