Inspiration

CloseChase came from a very practical bookkeeping problem: before month-end close, firms often know which transactions are unclear, but the answers are scattered across emails, messages, missing receipt requests, and vague client replies.

We wanted to build something narrow instead of another broad accounting dashboard. The goal was to help small bookkeeping firms and outsourced finance teams turn that messy follow-up process into one tracked workflow.

What it does

CloseChase helps bookkeeping firms collect missing transaction explanations and receipt context before close.

A firm can create a request batch, import or add unclear transactions, and send a private client portal link. The client does not need an account. They can answer questions, upload fake/demo-safe receipt context, and mark the batch ready.

The operator can then review the responses, approve or follow up, export CSV/text close notes, and explicitly close or revoke the portal when the work is done.

CloseChase also includes a client directory, workspace settings, manual reminder guidance, a close-period dashboard, export modes, and an activity timeline.

How we built it

CloseChase is built with Next.js App Router and deployed on Vercel. Clerk Organizations protects the operator workspace and provides the firm/org context.

DynamoDB is the primary backend database. We use it for firm-scoped workflow state: clients, workspace settings, batches, transactions, portal-token lookup by hash, client responses, client-ready state, review decisions, activity events, export metadata, and receipt metadata.

Receipt binaries are stored separately in private S3-compatible object storage. DynamoDB stores only the receipt metadata.

We also added bounded JSON parsing, route parameter validation, tenant-scoped repository access, guarded DynamoDB mutations, CSV import/export safety, formula-injection mitigation for exported CSV cells, and production smoke tests with fake data.

Challenges we ran into

The hardest part was keeping the scope narrow while still making the product feel like a real SaaS workflow.

A simple CRUD app would not have been enough. We had to think through tenant boundaries, tokenized client links, one-time link visibility, receipt metadata vs receipt binaries, review finality, portal revoke/close behavior, and how to keep the public client portal safe without forcing clients to create accounts.

Another challenge was staying honest about the product boundary. CloseChase is a production-shaped hackathon build and a controlled pilot workflow, but it does not claim active billing, QuickBooks/Xero write-back, AI/OCR, real email reminders, malware scanning, or full receipt-compliance readiness yet.

Accomplishments that we're proud of

We are proud that CloseChase is a real deployed workflow, not just a mockup.

The app supports a full fake-data close loop: create a batch, collect client explanations and receipt context, mark the client ready, review transactions, export close notes, and close the portal.

We are also proud of the DynamoDB architecture. The database is not just used as a generic JSON store; it supports firm-scoped access patterns, client profiles, batch records, transaction records, token-hash portal lookup, review queues, activity events, export metadata, and receipt metadata.

Finally, we are proud that we kept the product narrow. The app does one specific B2B workflow and tries to do it clearly.

What we learned

We learned a lot about designing DynamoDB around access patterns instead of treating it like a relational database or generic document store.

We also learned that product quality comes from boundaries: clear UX states, safe error handling, honest copy, production smoke tests, and not overclaiming.

The biggest lesson was that a strong B2B app does not need to be broad. It needs to solve one painful workflow clearly and reliably.

What's next for CloseChase

Next, we would add real email reminder delivery, stronger pilot onboarding, retention/deletion policy, malware scanning for real receipt files, audit-grade activity logging, billing, and eventually accounting-system integrations.

For this hackathon, we focused on the core workflow and the AWS database architecture: a real Vercel app backed primarily by DynamoDB, with a complete fake-data demo path from client request to review, export, and portal closeout.

Built With

Share this project:

Updates