Rocket Rebates
Find the rebates you qualify for, get an AI report on each, and file a package an admin has already checked.
- Role
- Solo Engineer
- When
- 2026
- Stack
- 1 × React
- 1 × Node.js
- 1 × Express
- 1 × PostgreSQL
- 1 × AWS RDS
- 1 × AWS S3
- 1 × OpenAI
- 1 × ETL
- 1 × Full-text search
The job
Rebate programs are scattered, worded differently and full of paperwork. Rocket Rebates pulled them into one place: search what is available near you, save the programs worth pursuing, get a clear report on each, and assemble an application that someone has checked before it goes out.
I built it solo at Bizdesire: the data model, the imports, the API, the AI workflows, document handling, the admin tools and both front ends.
How a user moved through it
- Search. Anyone could search local programs without an account.
- Project. To pursue programs, a user signed up and saved them to a project.
- Deeper search. Inside a project, search added program-specific filters and eligibility details.
- Report. For each program, OpenAI generated a report: what it is, what it requires, what it pays.
- Package. OpenAI also listed the documents the program needed. Generated reports and uploaded documents went to S3.
- Review. An admin checked the package in a dashboard and approved it.
- File. Only then could the user file it with the program.
A catalog from messy sources
Programs came from outside data sources with inconsistent fields. ETL jobs imported them into PostgreSQL on AWS RDS and normalised them into one schema: programs, eligibility rules, geographies and payouts, alongside the application's own tables for users, projects, reports, documents and review status.
Two kinds of search
Some questions are structural: which programs cover this area, pay in this range, fit this kind of applicant. Others are words typed into a box. Structured filters ran against indexed columns and keyword discovery ran through full-text search, so neither paid for the other's query patterns. The same layer served the public search and the deeper search inside a project.
AI as a step, not a chat
OpenAI calls were jobs with a defined input and output. Take this program record, produce that report. Take this program, produce its document checklist. The results were structured and went to a human for review, rather than free text dropped into the interface.
That separation mattered for trust. Producing a report did not make an application ready, and an admin, not the model, decided when a package could go.
Documents and the approval gate
Reports and uploaded documents lived in S3 and were shown through short-lived signed URLs, so admins reviewed the full package without files leaving the bucket.
A package moved through draft, ready for review, approved and submittable. The rule that nothing is filed without approval lived in the backend's status transitions, not only in the interface, so there was no way around it from the client.
Questions
- What was Rocket Rebates?
- A platform for finding and applying to local rebate programs. Anyone could search programs; signed-in users saved them to a project, generated an AI report on each, assembled the required documents and filed once an admin had approved the package.
- How did Rocket Rebates use AI?
- As two workflow steps rather than a chat: one OpenAI job turned a program's structured data into a detailed report, and another worked out which documents the program required. Both outputs were structured and reviewed before anything was filed.
- How did the admin approval gate work?
- A submission package moved through draft, ready for review, approved and submittable. The gate lived in the backend's status rules, not only in the interface, so nothing could be filed without an admin's approval.
Last updated