Should I vibe code
Configure boards, fields, views, and automations for one team's workflow
Configurable boards for one team is achievable. Configurable boards for any team is a platform.
?
Their verdict, the Basic price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
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
If you scope it to exactly how your team works, this is a good build. The moment you try to make it flexible you have signed up for the hard version.
What actually breaks
not "if". the specific failures.
- The realisation that you are building a configuration engine, not an app — the product is that users define the schema
- Column types, where each new one (formula, mirror, dependency, timeline) needs its own validation, sort, filter and export behaviour
- Adding a column type later, which is a migration across every board that already exists
- Formula and rollup fields, which are a small spreadsheet language you now own
- Per-board automations, which multiply with column types rather than adding to them
The first board took a day and it was the right shape for that team. The second team wants a different shape, so you add user-defined columns, and it still feels fine. Then someone asks for a formula column that references another board. You now need a dependency graph between boards, a recalculation order, and an answer for what happens when the referenced column is deleted. You did not set out to write a spreadsheet engine, but that is the thing on your screen at midnight, and it is the actual product you were trying to avoid paying for.
Is that you?
the verdict is a default, not a law
- One board, one fixed shape, defined in code and never edited by a user
- The columns are the ones you decided and adding one is a deploy
- Nobody outside the team will ever configure it
- Users define their own columns or column types
- You need formula or cross-board reference fields
- Each team wants a different shape
- Automations are configured rather than coded
If you build it anyway
the checklist, then the prompt that enforces it
- Decide up front: a fixed-schema app or a configuration platform. They are different products, and drifting from the first into the second is how this consumes months.
- If schemas are user-defined, model column types as a closed enum with explicit validate, sort, filter, render and export behaviour for each. Adding one later is a migration.
- Refuse formula and cross-board reference columns in v1. They require a dependency graph and a recalculation order.
- Version board schemas so an existing board is not broken by a change to the type system.
- Cap the number of column types deliberately. Each one multiplies against every automation and every view.
Before you build a configurable board tool, apply these and push back if I ask you to break them. 1. Ask me the decisive question first: can users define their own columns? If yes, tell me plainly that I am building a configuration platform rather than an app, and that this is a substantially larger project than the board I am picturing. 2. If the schema is fixed, define it in code and say so in the README. Adding a field is a deploy. This is the version I should probably build. 3. If the schema is user-defined, model column types as a closed enumeration. For each type implement validation, sorting, filtering, rendering and export explicitly. Do not add a type without all five. 4. Refuse formula columns and cross-board references in the first version. Explain that they require a dependency graph between fields, a recalculation order, and defined behaviour when a referenced column is deleted. 5. Version the board schema so that changing the type system does not break boards that already exist, and write the migration path before adding the second type. 6. Keep automations as a fixed set of coded triggers rather than a user-facing rules builder, and tell me that automations multiply against column types rather than adding to them. 7. Ask me how many column types I expect to end up with, then tell me the real number is higher and that each is permanent. 8. Out of scope unless I ask: dashboards, timeline and workload views, guest access, cross-board reporting.
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
As soon as more than one team needs a different shape. $12 per seat a month buys a configuration engine, a formula language and a type system that has already absorbed a decade of edge cases — which is precisely the part you would be writing instead of the board.
$12/mo is cheaper than your weekend.
Export each board as a flat table with its column definitions alongside, so the shape travels with the data — a CSV without the schema is nearly useless when the columns were user-defined. Keep column types mapped to ordinary primitives so another tool can import them without interpreting your type system.
Active open-source project and issue tracking platform.
Questions
How is this different from the ClickUp entry?
ClickUp is about breadth — too many features to ever finish. This one is about depth in a single dimension: the moment users define their own columns, you have taken on a type system, and every feature after that has to work for column types you have not invented yet.
Is a fixed-schema version actually useful?
Very. Most teams need one board with about eight columns they agreed on months ago. Building exactly that, in code, is a genuinely good weekend and skips the entire configuration-platform problem. The trap is adding 'let users add a field' later, which quietly changes what you are maintaining.
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.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice