Looking for a job has become a side job of its own: opening several job boards every day, rewriting your resume for each opening and, in the end, not knowing what is working. TrackVagas is a SaaS that takes that work off the shoulders of people who are job hunting.

It took 16 days from the first commit to going live. But "building a SaaS" is not just programming. In this post I explain what the product delivers and then cover every front that existed behind it: product design, design and animations, engineering, security, automated and manual testing, billing, and launch. I used AI as a working tool across several of them, and I explain where it helped and where the decisions stayed mine.

The Problem the Product Solves

People applying for jobs usually face the same three problems:

  1. Searching across several job boards is manual and repetitive. It means hours every week opening the same searches.

  2. The resume gets rewritten for every opening, but nobody keeps track of which version went where. When a reply arrives (or doesn't), there is no way to connect the result to the resume that was sent.

  3. Replies get lost. They arrive by email, WhatsApp, and job boards, and without a record you can't tell whether the problem is the job board, the resume, or the type of role.

The result is applying in the dark. TrackVagas starts from a simple question: what actually generates replies?

What the Product Delivers

  • Daily searches across the main job boards, with filters (work model, seniority, location, and more). Openings arrive ranked by how well they match your resume.

  • A master resume in Portuguese, English, and Spanish, plus versions by job type. An approved version never changes, and the database guarantees it.

  • AI adaptation that rewrites the resume for a given job without making up experience.

  • Email replies logged automatically: a forwarding rule in Outlook or Gmail, and the app recognizes interviews, rejections, and confirmations.

  • Metrics: funnel, response rate, and interview rate by job board, resume version, technology, work model, and seniority.

  • Your data is yours: export everything (a ZIP with JSON, CSVs, and PDFs) and delete the account inside the app.

Behind the Product

A real product doesn't come from "writing code": it comes from understanding the problem, designing the solution, building it securely, and testing before delivering. These are the fronts that existed behind TrackVagas.

1. Product Design: Before Any Code

The first week wasn't about code. It was about deciding what to build and what to leave out:

  • Mapping the business and the problem in 15 points (who feels the pain, what the risks are, whether it's worth building), with one explicit decision: start as a personal tool and only turn it into a product if it made sense. It did, and from then on the project was built "as if it could become a product": a public landing page and each user's data isolated.

  • A requirements document (PRD) with the problem, measurable goals, the scope of the first version (MVP), and stages. Every scope change went into a history.

  • Small stages: master resume, jobs, import, applications, replies, metrics, resumes by job type, AI. Each one reached production before the next.

  • 91 recorded decisions in a short format (problem, choice, why). They became the project's memory: when I came back to a topic, the conversation started from the record, not from zero.

  • Name, logo, and domain chosen by me. The product began under a different working name; the name TrackVagas, the blue magnifying glass with the yellow briefcase, and the trackvagas.com.br domain were my decisions. A brand is part of the product, not decoration.

  • The job posting at the center of the model. A product decision that changed the landing page's language and opened the way for a future recruiter environment: an application is just the link between a person and a job.

One rule guided everything: no new service enters the project without a conscious decision and a record of the reason and the cost.

2. Design and Animations: AI Helps, the Eye Decides

The visual identity was decided early on (navy ink with highlighter yellow and, later, the name, the magnifying glass and briefcase logo, the favicon, and the domain), and it is protected: it isn't reinvented on every screen.

  • A landing page with animated demonstrations: a living spreadsheet at the top and a "Record, adapt, measure" section with a demo app showing searches arriving, jobs being saved, and replies coming in. It's code, not video, and the "fictional data" label makes clear these are examples.

  • Specialized instructions (skills) that guided the AI on each interface task: one for design direction and audits, another against generic interfaces, one for finishing details, one for motion and another for animation review, one to make the app feel native on a phone (PWA), and one that tries to break the screen with extreme data (huge names, empty lists, long texts).

  • Manual adjustment, all the time. AI produces good first drafts; the finishing is my call: spacing, the hierarchy of each screen, touch target size on mobile, what animates and what stays still, the wording of every button. Much of the review was me looking at the app in the browser and on my phone and asking for (or making) the fix.

  • Accessibility and dark theme treated as part of the job, not as extras.

Design lesson: AI speeds up the draft, but "beautiful" and "clear" are still human judgments.

3. Engineering

  • Nuxt 4 and TypeScript for screens and server routes in a single framework.

  • Nuxt UI (Tailwind 4) for accessible components and token-based theming.

  • Supabase (Postgres, Auth, Storage): real SQL for the metrics and RLS to isolate data.

  • Cloudflare Workers for hosting: cheap, fast, a deploy on every merge.

  • Apify for the searches, because job boards have no open API.

  • Resend to receive the forwarded email and notify the app through a webhook.

  • Gemini for AI, behind a layer that makes it possible to switch providers.

  • Asaas for billing: recurring card payments in Brazilian reais, with a webhook.

  • Zod for validation: the same schema applies to the form, the API, and the AI response.

A few hard problems are worth telling:

  • Each person's data isolated in the database. Every table has a user_id and an RLS policy. I don't rely only on application code.

  • The server owns sensitive state. Plan, limits, and AI usage can't be written by the browser.

  • AI that doesn't make things up. The prompt only allows reordering and rephrasing what exists in the master resume; the output is validated; the screen shows "what changed compared to the master," with a way back to the original. I also tested a job posting that tries to send instructions to the model.

  • Email replies without reading anyone's inbox. Each user has their own address and creates a forwarding rule; I never ask for inbox access.

  • Platform limits. The Worker's CPU limit led me to move heavy work to the browser and keep screens static.

4. Security

  • Per-account isolation tested in the database, not just in code.

  • A separate admin environment: its own subdomain, mandatory second factor, and an audit log of every admin action.

  • Production keys only as secrets on the hosting platform, never in code or AI prompts. When a key became visible, I replaced it.

  • A full security audit before opening, run with a dedicated skill. The findings were fixed in separate pull requests, before launch.

  • Data protection in the product: export all data and delete the account in the app, a privacy policy, and terms of use.

5. Testing: Automated and Manual

Automated

  • More than 350 business-rule tests (metrics, application statuses, plans, billing, AI validation).

  • 289 database checks (pgTAP): what each user can read and write, triggers, and plan rules.

  • Lint, type checks, and tests running on every pull request.

Manual, and there was a lot of it

  • Every screen checked in the browser and on mobile, in light and dark themes, with normal and extreme data.

  • End-to-end flows with test accounts: sign-up, password reset, search, save, apply, log a reply.

  • Billing in the simulation environment and then in production with a real card, including cancellation and refund. This is where the bug that the simulation hid showed up: the refund returned the money and removed paid access from the account, but the subscription stayed active in Asaas and would have charged again the following month. I fixed it (the refund notice now cancels the subscription) and covered it with a test. Test real money, end to end, refund included.

  • Rounds of adjustments after every test: several pull requests just for "I used it and noticed that…".

6. Billing and Operations

Recurring card subscriptions, a webhook with a token compared in constant time, a daily task that ends expired subscriptions, special access that only the administrator can grant, and an admin panel with metrics, costs, and visitors. A custom domain, transactional emails, and a business account all set up.

What This Process Delivers

Looking back, these are the marks of a product built with care:

  • A start that isn't code: understanding the business, the problem, and what isn't worth building yet.

  • Delivery in small stages, each one in production, so you can see and weigh in while the system grows.

  • Careful design and finishing, with its own identity, not just functional screens.

  • Security and testing from the start, not as a patch at the end.

  • AI as a tool, with human accountability for what goes live.

  • Attention to what was delivered: fixes, adjustments, and evolution after launch.

Project Numbers

  • 16 days between the first commit (October 5, 2026) and launch.

  • Around 170 commits and dozens of small pull requests.

  • 37 database migrations and 91 recorded decisions.

  • 350+ tests of business rules and 289 database checks.

What I Would Do Differently

  • Test real billing earlier. The refund bug only showed up there.

  • Get outside users in sooner. Small details (a logo click that didn't scroll back to the top, tab counts that were missing) only appeared in real use.

  • Keep fewer loose settings in dashboard variables. Now everything goes straight in as a secret.

What Comes Next

The launch is just the beginning. The product is taking shape, and the next phase is growing it, with a focus on marketing and distribution, plus new features (such as an environment for recruiters, more languages, and more job boards). And, of course, listening to the people who use it. TrackVagas is already live at trackvagas.com.br.

If you're job hunting, just give it a try. And if you have a company, a manual process, or a product idea that could become software, and you want to understand what it would take to get it off the ground, just reach out! 😉✌🏽