AI workflow, Fintech, Web
Building a fintech product with no engineering team, with Claude as the executor. A financial platform for shift-based physicians.
- Role
- Senior Product Designer
- Team
- Product Designer and Data Analyst
- Date
- 2026
- Platform
- Web
The idea behind it
Jaleco is a financial platform for shift-based physicians, built by two people and no engineering team. I designed the delivery flow before any product code existed: I own every product and interface decision, a data analyst owns the database, and Claude executes inside a design system I control.
A shift-based physician is paid per shift, by several hospitals, each on its own schedule, often one or two months after the work was done. A Google Sheets file tracked it all, and could not answer the questions a physician asks every month.
- How much have I worked this month, and where?
- What has been paid, what is still pending, and what is late?
- What is my real income this month? It depends on when a shift is paid, not when it was worked.
- How do income, expenses and savings goals look together?
Answering any of them meant manual formulas, a tab per month and data typed again by hand. Nothing connected a shift to its payment, and one wrong cell changed the month's result without anyone noticing.
Two people can own a real product when Claude only executes, inside a system I designed. That works only if it is clear who decides what.
Me, Senior Product Designer
The product
Strategy, every screen, the design system, Design Review and the final approval to ship.
Senior Data Analyst
The database
Schema and migrations, the local database with fictional data, production, backups and access rules.
Claude
Execution
Builds what the two of us decide, inside the system we designed. It never decides what ships.
I designed this flow before any product code existed, and revised it over several rounds until every step had an owner. It is how every change reaches the two physicians.
Every iteration happens on localhost, against a local database with fictional data and the same structure as production. Nothing is published to be reviewed, and real data exists only in production.
Three of the seven steps are mine, the ones that depend on judgment: framing the problem, reviewing the result and approving what ships.
New request
Frame the problem
Before anything is built, I decide what the user needs to answer, what the screen shows and which rules it follows.
Design Review
Judge the result
I review it as a product. I ask for tweaks, add a component to the design system, or approve. If a fix from the checks changes anything visible, it comes back to me.
Merge
Approve what ships
My final approval, once the checks pass. Nothing reaches production without it, and I am accountable for what does.
Claude builds every screen from a design system that lives in my own repository, separate from the product. It is the only source of interface: its catalog ships inside the package and is written for an AI reader, with every token and component and the rules for using them.
When a screen needs something the design system does not have, Claude does not improvise. It reports what is missing, and I decide whether it belongs in the design system or stays in the product. From there the process is automated: the new component arrives in the design system repository as a pull request, and I approve it. The release updates Storybook and the package, and the product imports the new version.
At one point Claude suggested swapping my design system for an off-the-shelf one. I weighed what that would do to the architecture and kept mine: it is shared across products, and its rules carry decisions I do not want to make again.
Then I wrote the decision into the rules Claude loads at the start of every session. The design system is the only source of components, and a check fails the build if the product points at anything other than a released version.
Before settling on a build tool I asked why not Next.js. Jaleco is a private app behind a sign-in: it runs in the browser, and Supabase is the backend.
Next.js would bring server rendering the product does not need. I chose Vite on those trade-offs.
Jaleco is in testing with two physicians. Each one signs in and sees only their own data.
The questions the spreadsheet could not answer are now answered by rules built into the product: a shift's status is derived from its dates, never typed, and a month's income is counted by payment date, not by shift date.
