The problem
The spreadsheet starts simple. One tab, one row per person per week, columns for Monday through Sunday, a project code, notes. Then someone adds a second project row, a rate column, a pivot tab for finance, a hidden tab for bill rates. Now there are five tabs and no one agrees which one is current.
Concrete failure modes show up fast. Two people open the file, last save wins. Someone types 8 into Monday as text, SUM ignores it. A project code is misspelled, so hours vanish from the rollup. A closed project still appears in the dropdown because nobody updated the list. People copy last week's row, including hours, and submit. Finance asks for a correction and you cannot tell who changed the number or when.
The spreadsheet also leaks. Share settings spread over time. Contractors get edit access to a tab with bill rates. Someone downloads a copy to a laptop, and now there are three versions of the truth. Month end becomes a forensic exercise: reconcile totals, chase missing weeks, rebuild the pivot, paste into the invoicing sheet. The work is not hard, but it is constant and it hides errors until a client questions an invoice.
What a good solution looks like
The app should do one job: capture time against projects, get it approved, and export it. That means four or five screens, not a platform. A week view with a row per project and a column per day. A project picker that reads from a real project table. A submit button. An approval queue for managers. A small admin area for people, projects and rates.
The rules belong in the app, not in a memo. Closed projects cannot be selected. Hours per day have a maximum. Time can be entered only for the current week and the prior two, unless an admin reopens a period. Notes are required when hours exceed a threshold or when a project is marked as internal. Every edit after submission requires a reason and lands in the change history with user, timestamp, old value and new value.
Roles matter more than features. An employee sees their own time. An approver sees their team. Finance sees approved hours and can export, but not edit. Admin manages projects and people. Keep bill rates in a separate table with its own permission, so the entry screen never shows money to people who do not need it.
Design for the phone. Most time entry happens on Friday afternoon or Monday morning, often from home. Make the week view readable at 375 pixels wide, keep the submit action at the top, and do not require horizontal scrolling to reach Friday. Make exports boring and stable: fixed column names, ISO dates, decimal hours or minutes, one row per entry or per person-project-week, and a total row that finance can check.
How to build it
Start by writing the rules on one page. Who enters time, who approves, what counts as late, which projects are open, how corrections work. Then model the data. You need people, projects, time entries, approvals and an audit log. A time entry is one row per person, project, date and note, with minutes stored as an integer. Do not store hours as a float. Round only at export, and write the rounding rule down.
Pick the identity path first, because it shapes everything else. If your company uses Google Workspace or Microsoft Entra, sign in with that and map roles to groups. Do not build a password reset flow for an internal tool. Then build in this order: the week entry screen, server-side validation, submit and lock, approval queue, exports, admin screens. Ship the entry screen to five people before you build reports.
Migrate with a parallel run. Import the current project list and the last two periods of entries from the spreadsheet. Clean project codes first, because duplicates and typos will follow you forever. Map people by email, not by display name. Run the app and the spreadsheet side by side for one or two pay periods, with the app as the source of truth and the spreadsheet read only for reference.
Finish with training and a runbook. A twenty minute session that covers entering a week, submitting, correcting a rejected week, and exporting is enough. The runbook should list who can reopen a period, how to add a project, how to fix a wrong approver, and where exports land. Test the export against a fake finance import before the first real close.
Risks and how to manage them
Scope creep is the main one. The first request after launch is usually a dashboard, then a budget burn report, then a client portal. Keep a visible backlog and say no for the first month. The app wins if people trust the entry and approval loop.
Late and missing time. Set a weekly deadline, for example Monday at noon for the prior week, and have the app send a reminder to anyone who has not submitted. Managers should approve by end of day Tuesday. If approvals lag, finance waits, so measure approval turnaround from day one.
Shadow copies. People will keep a personal spreadsheet unless you give them a reason to stop. Announce a cutoff date, make the old file read only, move it to an archive folder, and make the app's export good enough that no one needs a private copy. Keep the archive for the retention period your finance team requires.
Key-person risk and quiet drift. Two admins, not one. A runbook that lives with the code. A monthly review of open projects, inactive people and rejected entries. Watch for the eight hours every day pattern, where people fill a default day instead of real project time, because that erodes the value of the whole system.
How to measure success
Measure the loop, not the app. Percentage of people who submit by the deadline. Median hours from submission to approval. Number of corrections per pay period. Time finance spends reconciling before export. Number of spreadsheet copies still in circulation. These are easy to count and they tell you whether the app is working.
Run a trace. Pick one recent week. Choose three entries at random and follow them from the app to the approval to the export to the invoice or payroll line. If you cannot complete the trace without asking a person, you have a gap. Do this once a month for the first quarter.
Ask the people who use it. Can a new hire enter a full week without a call? Can a manager approve a team of ten in five minutes? Can finance close the period without opening the old spreadsheet? If the answers are yes, the app has replaced the spreadsheet.
If you want outside help, Cloudverg's Internal tool sprint is a fixed price of $16,500 for four weeks, starting within 10 business days. It covers one workflow end to end, sign-in with your identity provider, roles and permissions, change history, import of your current data, CSV exports, a training session and a written runbook. It is one option among others, and it suits teams that want the project done this quarter.
Frequently asked questions
Can we just improve the spreadsheet instead of building an app?
Up to a point. You can add data validation, lock cells and split rates into a separate file. But a spreadsheet cannot enforce approvals, keep an audit trail or stop two people from overwriting each other. Once more than a few people enter time weekly, the controls cost more than a small app.
What is the smallest useful version of a time tracking app?
A week view, a project picker, submit and lock, an approval queue, and a CSV export. That is enough to replace the spreadsheet. Reports and dashboards can wait until people trust the entry loop.
How do we handle corrections after a week is approved?
Reopen the week with a reason, let the person edit, and require re-approval. Keep both versions in the change history so finance can see what changed. Do not edit approved entries directly in the database.