CTK is an architecture firm, and this is the largest thing I have built through Korrit. They came wanting their timesheets and their billing to stop being two separate jobs done by hand, and what they described was a form: everybody types their hours in one place, somebody approves them, an invoice comes out of the other end.

The constraint was that both ends already belonged to somebody else. Their entire history sat inside Monograph, which is practice management software an architecture firm rents by the month, and their bookkeeping sat inside QuickBooks, which they were not going to leave and should not have to. So the useful version of this was never the form. It was getting the data out of the product that was renting it back to them and into a Postgres database with their name on it, then handing the invoice end back to QuickBooks and building only the middle.

The middle is a weekly timesheet with a row per project and a cell per day, an approvals queue that groups one card per person per month, a set of rules about when a finished month stops being editable, and a push into QuickBooks the moment a manager approves. There is also a chat box that answers questions about the database in plain English, which nobody asked for.

Writing the rules down is what found the bugs. Late on, the app got a Policies page stating in plain English how a month closes: it stays open through the Sunday ending the week that contains the first Monday of the next month, the hours report reaches the office manager the day after that Monday, and the lock always lands on a Monday between the eighth and the fourteenth. The page derives its worked example from the same function that enforces the rule, so the two cannot drift apart. Then I went looking for whether the code backed every sentence, and twice it did not. The lock guard took today from a plain date constructor, and Vercel runs its functions in UTC, so from eight in the evening Eastern the server already believed it was tomorrow and the month shut four hours early, inside the window the page had promised. Deleting an entry never checked the lock at all, only creating and editing did. A rule you have written down for users is a claim about your code, and I had made two I could not back.

The three weeks I spent on invoicing were three weeks spent rebuilding something the firm was already paying QuickBooks to do. I should have begun by asking which of the systems they already run is going to keep owning which part of this, and drawn those lines before writing anything, instead of finding them by deleting a fortnight of work. I made the same mistake smaller in April, building a whole guides section over two days and removing it in May. The lesson is waiting at the far end too: time off balances are meant to come from ADP, where payroll actually lives, and that integration is written up and not built, because reaching it needs CTK to buy a thousand dollar add-on and issue certificates from their own account. None of that is a coding problem and it has held the feature for months. Building the thing is fast enough now that building the wrong thing is the expensive part.