Should I vibe code
Flat-price project planning, discussions, proofing, files, and reporting
"Approved" is not a checkbox. It's the row you cite when someone asks who pays for the reprint.
?
Their verdict, the Essential 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
Take the invoicing out of the Teamwork entry and you might expect a gentler verdict. You get a different one instead, because the word in the name is the risk. Proofing is not commenting — it is a client marking up version three of a file and clicking a button that means yes, print it. That click is the row you will be asked to produce when ten thousand brochures come back with the old strapline, and it is only worth producing if it references a hash of the exact file the client was looking at, which is precisely the detail a generated implementation will not include. Around it sits the other classic: a flat-priced tool with unlimited users is a tool where somebody adds a client at four in the afternoon without thinking, and the file viewer takes an id from the URL. Build the board, the discussions and the calendar for your own team. The approval record and the external login are the two things worth paying for.
What actually breaks
not "if". the specific failures.
- The approval, when it records a project and a timestamp but not a hash of the file version, so nobody can prove afterwards which artwork was actually approved
- File versioning, where the viewer takes a version id from the query string and the annotation layer is rendered from the latest upload instead of the approved one
- The client role, which starts as a deny-by-default idea and becomes a boolean somebody checks in a template, at which point one client can request another's project by id
- Attachment URLs, because uploaded files served from a guessable path are readable by anyone who has ever been sent a link, including the contractor who left
- Notifications, which are the reason a team adopts a tool at all and are also how a comment intended for the internal thread reaches the client's inbox
- Storage growth, since a proofing tool holds every version of every large asset forever and nobody wants to be the one who deletes v2
- Uptime, on the day the client's sign-off deadline is Friday and your deploy was Thursday night
- Time tracking, which looks harmless until someone exports it and treats the total as billable, at which point read the Teamwork entry
- Custom roles, which are a permissions matrix, and a permissions matrix without a test suite is a list of assumptions
The reprint quote lands at 09:12 and it is eleven thousand euros. The client's marketing lead is polite but firm: she approved version three on the fourteenth, and the brochure that shipped carries the old strapline. You open the approval record and it says exactly what you designed it to say — project, user, timestamp, "approved". It does not say which file. The viewer resolved the asset by project id and served whatever the newest upload was, and a designer had pushed v4 at 17:40 that afternoon while the review link was still open in someone's browser. There is no hash, no immutable version pointer and no render of what she actually saw. Both stories are internally consistent and your database cannot distinguish them. While you are working out how to write that email, someone forwards you a screenshot from a different client's review link, which they reached from your app because the shared-file route never checked whose project it belonged to.
Is that you?
the verdict is a default, not a law
- It is internal only — no client accounts, no guest logins, no shared review links
- Approvals are recorded somewhere else entirely, in email or a signed PDF, by a human
- The files in it are things you would not mind seeing on someone else's screen
- Losing the whole database would cost you a weekend rather than a client relationship
- Clients log in to it, even to a single read-only page
- A click in your app is what "signed off" means in your process
- You have not written the test that authenticates as client A and asks for client B's file, comment, export and download URL
- Files are served from URLs that are not authorised on every single request
If you build it anyway
the checklist, then the prompt that enforces it
- Make the approval immutable and self-describing: it stores the file id, the version id, a content hash and, ideally, a rendered snapshot of exactly what the approver saw. Anything less is a timestamp with an opinion attached.
- Version files properly and never resolve an asset by "latest". A review link points at one immutable version and keeps pointing at it after somebody uploads another one.
- Scope every query by account at the data layer, not the controller and never the template. Then write the cross-tenant test — authenticate as client A, request client B's project, file, comment, export and download, assert 404 on all of them.
- Serve every attachment through an authorised handler or a short-lived signed URL. Uploaded files on a guessable path are the oldest bug in this category and the one nobody notices.
- Client users are a separate role with deny-by-default permissions, and adding an endpoint forces an explicit decision about whether clients can reach it.
- Split internal from client-visible at the schema level, not with a flag in the UI. An internal comment that can accidentally render in the client view is one boolean away in most designs.
- Log every permission change, every approval and every share link with who, when and from where. That log is the entirety of your evidence in a dispute.
- Decide the storage retention rule before the first upload, because a proofing tool accumulates enormous files and nobody ever volunteers to delete a version.
I am building a project tool with client access: projects, tasks, discussions, file uploads, and a proofing flow where a client marks up a file and approves it. Treat the approval record and the tenant boundary as the parts that end up in an argument, and build them first.
1. Define the tenancy model before any feature. Every query is scoped by account at the data
layer, and there is no code path that fetches a row without one. Show me where that is
enforced and prove there is no route around it.
2. Write the cross-tenant test second, before the features it protects: authenticate as client
A and request client B's project, file, file version, comment, export and download URL.
Assert 404 on every one.
3. The approval record is immutable and stores file id, version id, a content hash of the exact
bytes reviewed, the approver, the timestamp and the comment thread state. If you cannot
store the hash, say so loudly rather than shipping a timestamp.
4. Files are versioned and every review link points at one immutable version. Nothing in the
system resolves an asset by "latest". Uploading a new version must not change what an open
review link is showing.
5. Serve every attachment through an authorised handler or a signed URL with a short expiry.
No guessable paths, no permanently public bucket objects, no exceptions for thumbnails.
6. Client users are a distinct role, deny-by-default. Adding any endpoint requires an explicit
decision about client visibility, recorded in code.
7. Internal and client-visible content are separated in the schema, not by a flag in a
template. Show me what stops an internal comment rendering in the client view.
8. Build an audit log before the dashboards: approvals, permission changes, share links created
and revoked, file versions uploaded and deleted.
9. Decide file retention now — how many versions, how long, who can delete — and implement the
deletion path before the upload path is finished.
10. Build the export early: projects, tasks, comments, file versions and approvals, as JSON
plus the files themselves.
11. Out of scope unless I ask again: invoicing, billable time totals, white-labelled domains and
anything that emails a client automatically.
12. Finish by telling me that fifty dollars a month flat, for unlimited users, is less than one
disputed reprint, and ask whether I really want to own the sentence "the system says you
approved it".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
The moment a client can log in, or an approval in your app is what "signed off" means. ProofHub is flat-priced at fifty dollars a month for unlimited users, which is unusual in this category and makes the arithmetic easy: it is roughly one hour of your time a month to not own a tenancy model, a file-serving layer and an approval record that has to hold up in an argument. Build the internal board if you want one — that part is a genuinely good weekend with a blast radius of you.
$50/mo is cheaper than your weekend.
Everything a client can see is something you will have to hand back, so build the export before the second feature: projects, tasks, comments, file versions and approval records as JSON, with the files themselves in a folder structure that makes sense to a human. Keep the approvals in an append-only table you can dump independently, because that is the artefact with a shelf life measured in years rather than sprints. If external users have logins, write down now how they get their history and how their access ends, and give them notice — a review portal that disappears mid-project is a conversation with the person who pays you. Vikunja and Plane both import from CSV, so shaping your export towards theirs costs nothing today.
Actively developed open-source project and issue tracker covering the planning half without the client-facing half.
Open-source task and project manager with lists, boards and teams, and a sane permissions model to read before writing your own.
Questions
ProofHub has no invoicing. Why is it still YOUR FUNERAL?
Because the approval is the money. Teamwork's risk is that a number on an invoice is wrong; ProofHub's is that a record saying a client approved something has to survive being questioned, and an approval that does not pin the exact file version is not evidence of anything. Add external logins to that and you have the two ingredients this site cares about: a failure that lands on somebody who did not choose your code, and an artefact you cannot reconstruct after the fact.
Is flat pricing with unlimited users relevant to the risk?
More than it looks. Per-seat pricing creates friction that accidentally functions as access control — somebody has to approve the spend before a new person gets in. Flat pricing removes that, which is great for adoption and means external people get added casually, by whoever is in a hurry. If you rebuild the model, rebuild the permission discipline that per-seat billing was quietly providing for free.
Can I build the internal half and keep clients out?
Yes, and it is the split we would recommend. Projects, tasks, discussions, files and a calendar for your own team is a good self-built tool: everyone in it chose to be, and the worst outcome is annoyance. The moment an external account exists, or a click in your app means sign-off, you have taken on both problems in this entry at once.
- GDPR Art. 5 — principles relating to processing of personal data
- GDPR Art. 32 — security of processing
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.
The timer isn't a timer. It's the first line of an invoice you will have to defend to a client.
Tasks, docs, goals, dashboards and automations. That is five products and you want all five.
Project management tools are easy to build and impossible to get a team to adopt.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice