ClickContas
liveModular accounting SaaS
Multi-tenant platform that digitises an accounting firm's routine: AI reads handwritten timesheets, and a shared cash book lets each client company post its own entries for the accountant to reconcile.
- Next.js
- TypeScript
- React
- Tailwind
- PostgreSQL (Supabase)
- Google Sheets API
- Google Gemini
- Vercel
● Private client product — case study only, with fictional-data mockups of the real screens.
// the case
- problem
- The firm ran two routines by hand: retyping photographed handwritten timesheets into a spreadsheet, one at a time, and posting each client's cash movements that arrived by WhatsApp or on paper — with no standard and no consolidated view.
- solution
- Two independent modules on one multi-tenant platform. Gemini reads the photographed timesheet and a side-by-side review screen applies the business rules; the client company posts its own cash entries against a chart of accounts the accountant standardised, and she reconciles and closes the month.
- impact
- In production with real clients. The work that used to be retyping is now review, and the loop closes on itself: the system generates the blank timesheet, the client fills it in by hand, a photo goes back in, and the spreadsheet comes out.
// my role
Full-stack, solo — product, architecture, front end, back end and deployment.
// overview
Three roles share the platform, and what each one can reach is decided on the server: a master admin who registers accountants, the accountant who sees only her own companies and the modules she was given, and the client company's admin who reaches nothing but its own cash book. Every client company carries an immutable internal id, so renaming a legal entity or filling in its tax number later breaks no link.
The two modules don't share a database, on purpose. The cash book is concurrent, relational and needs integrity, so it lives in PostgreSQL. The timesheet data lives in Google Sheets because the accountant already worked in a spreadsheet — meeting the tool where she was, rather than making her migrate to be allowed to use the product.
// engineering notes
OCR with a human in the loop
The model extracts the times; the decision stays with a review screen that applies each company's working hours, holidays, days off and daily balance. Automation that stays auditable — an accountant signs off on numbers she can still see next to the original photo.
Two databases, chosen per access pattern
PostgreSQL for the cash book, where several companies write at once and referential integrity matters; Google Sheets for the timesheet, read and written through the API. One company id stitches the two together, validated in the application since there can be no foreign key across them.
Authorisation in depth
Middleware makes the coarse cut by role; every API route then asks the narrower question — may this user touch this company? Sessions are signed cookies (HMAC) and passwords are PBKDF2, both through Web Crypto so they run in the edge runtime. RLS is on with no policies, so the browser's public key reads nothing directly.
Migrating a live system
Part of the registry was born in Google Sheets and moved to PostgreSQL with the system already in production. Keeping the function signatures identical meant the backend swap touched no call site, and existing data and passwords came across intact.