Should I vibe code
Plan client projects, log time, manage milestones, and expose a client view
The timer isn't a timer. It's the first line of an invoice you will have to defend to a client.
?
Their verdict, the Basics 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
Asana's entry says the honest thing about task trackers: tasks with owners and dates are a weekend, and the reason teams pay is notifications and adoption. Teamwork is that plus a billing department. Hours logged against a task become billable amounts, billable amounts become an invoice, and the clients being invoiced get their own login to watch the work happen. That changes what a bug costs. A timer left running overnight is not a cosmetic glitch, it is six hours on somebody's bill. A rate change applied to entries that predate it silently reprints an invoice you already sent. And the client portal is the single most confidently generated, most subtly wrong thing an agent will write for you: one report endpoint that filters in the view rather than the query, and the client reading it can see the margin on the account next door. Build the board. Do not build the ledger.
What actually breaks
not "if". the specific failures.
- Timers: two running at once, one left going over a weekend, one still counting on a laptop that went to sleep — each is a line item somebody has to explain
- Rounding, because rounding every entry up to the nearest fifteen minutes across three hundred entries is real money and a real argument, and nobody agreed the rule in writing
- Rate changes, when a new rate joins to old time entries and last quarter's report no longer matches the invoice you actually sent
- The client view, where a single report endpoint that filters in the template instead of the query shows one client the budget and margin of another
- Edited and deleted time entries, which without an audit trail leave you unable to show what the invoice was built from when somebody asks
- Tax and currency on anything invoice-shaped, which is the part people discover after the first cross-border client
- Notifications, which are the actual reason a team adopts a tracker and the thing homemade versions never get right
- Uptime, because the day your delivery process lives here is the day a Saturday deploy becomes everyone's problem
The quarterly review is at nine and the client's finance lead has asked for the backup behind a £14,200 invoice. You export the time entries and the total comes out £900 short, because a rate rise went in during March and your report joins live to the rate table rather than the rate that applied on the day. While you are working out how to explain that, the same finance lead replies to say she has been looking at the delivery dashboard link you sent, and asks — politely, curiously — why she can see a project called Northgate Rebrand, which is not hers. The report page took an id from the URL, and the tenant filter lived in the template.
Is that you?
the verdict is a default, not a law
- It is internal only, with no client logins and no external users of any kind
- Time tracking exists for your own curiosity and no invoice is derived from it
- Invoices are produced in real accounting software by a human who checked the numbers
- Losing the whole database would be annoying rather than a dispute
- Clients log in to it
- An invoice amount is computed from rows in your database
- You have not written the test that logs in as one client and requests another client's ids
- Rates change over time and you are storing them in one mutable column
If you build it anyway
the checklist, then the prompt that enforces it
- Do not generate invoices. Produce a reviewed timesheet and hand it to real invoicing software — the tool that already knows about tax, sequential numbering and credit notes.
- Scope every query by tenant at the data layer, not in the controller and never in the template. Then write the test that authenticates as client A, requests client B's project ids, and asserts a 404.
- Snapshot the billable rate onto the time entry at the moment it is written. Never join a printed figure to a mutable rate table, or history rewrites itself every time somebody gets a raise.
- Make time entries append-only. Corrections are new rows with a reason and an author, and any total you show references the entry ids it was built from.
- Round once, at the invoice, using a rule that is written in the contract. Per-entry rounding is where the trust goes.
- Give timers a maximum duration, an idle prompt and an automatic stop that flags rather than bills. Nobody worked fourteen hours straight.
- Nothing a client can reach is served from a guessable id without an authorization check on every request, including exports, PDFs and shared report links.
I am building an agency project tool: projects, tasks, time tracking, and a portal where clients log in to see their own work. Treat the money and the tenancy as the dangerous parts and refuse to rush them.
1. Before any feature work, define the tenancy model and enforce it at the data
layer — every query scoped by account, with no way to fetch a row without one.
Show me where that is enforced and prove there is no path around it.
2. Write the cross-tenant test first: authenticate as client A, request client B's
project, task, report, export and PDF by id, and assert 404 on every one.
3. Refuse to generate invoices. This system produces a reviewed timesheet and
exports it; the invoice is created in accounting software.
4. Store the billable rate on the time entry at write time. Never compute a
historical total by joining to a current rate table, and explain what happens
to last quarter's report when somebody's rate changes.
5. Time entries are append-only. Edits and deletions create new rows with an
author, a timestamp and a reason, and any displayed total must be traceable to
the entry ids behind it.
6. Timers get a maximum duration, an idle check and an automatic stop that flags
the entry for review instead of billing it. A timer left running over a weekend
must never silently become a line item.
7. Round only once, at the point of export, with the rule stated on screen. Refuse
per-entry rounding and tell me it is the thing clients notice.
8. Client users are a separate role with a deny-by-default permission set. A new
endpoint requires an explicit decision about whether clients can see it.
9. Log every permission grant, rate change and time-entry correction with who did
it and when. That log is the only evidence I will have in a dispute.
10. Build the export before the dashboards: projects, tasks and time entries with
snapshotted rates, as CSV.
11. Out of scope unless I ask again: automated invoicing, payment collection,
profitability forecasting, anything that emails a client automatically.
12. Finish by telling me that $10 a seat a month buys a permission model somebody
has already got wrong and fixed, and that one disputed invoice costs more.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 invoice is derived from a row in your database. Around $10 a seat a month billed annually buys a tenancy model that has already been audited, time entries with an audit trail, and invoice logic that has met tax, currency and credit notes. Building the internal board is a good weekend. Building the part that decides what a client owes you, and what a client can see, is not.
$9.99/mo is cheaper than your weekend.
Export projects, tasks and time entries — with the rate snapshotted on each entry and the correction history intact — to CSV on a schedule, and keep the invoices themselves in accounting software from day one so the billing record never depended on your app. If clients have logins, write down now how they get their history and how their access is revoked when this stops, because a portal that vanishes without notice is a conversation with the person who pays you.
Active open-source project and issue tracker; covers the planning half without the billing half.
Mature open-source time tracker built for agencies, with rates, customers and exports already thought through.
Questions
Asana is DEMO ONLY and Teamwork is YOUR FUNERAL. Why the gap?
Asana's failure mode is that nobody adopts it, which costs you a weekend. Teamwork's failure mode is a number on an invoice and a client seeing another client's account. Both are buildable; only one of them ends with an email you have to write to somebody who pays you. The verdict tracks who absorbs the mistake, not how hard the code is.
Can I build the internal side and keep clients out of it?
Yes, and that is the sensible split. Projects, tasks, milestones and time tracking for your own team, with exports going to whatever produces the invoices, is a genuinely good self-built tool with a bounded blast radius. The moment you add an external login or compute a billable total, you have taken on the two problems this entry is about.
Why is snapshotting the rate such a big deal?
Because reports are read months after the work. If a total is computed by joining time entries to the current rate, every historical report changes the day somebody's rate changes, and the version a client received will not match the version you can reproduce. Copying the rate onto the entry at write time costs one column and makes every past invoice reproducible forever.
- IRS — what kind of records should I keep
- European Commission — EU VAT invoicing rules
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.
Project management tools are easy to build and impossible to get a team to adopt.
Tasks, docs, goals, dashboards and automations. That is five products and you want all five.
Configurable boards for one team is achievable. Configurable boards for any team is a platform.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice