At a glance
Role. Founding Designer. Research, brand, UX, frontend, backend, launch and campaigns. Two founders brought the idea and run the business day to day: they recruit professionals and validate payments.
Timeline. February to September 2026. From idea to production in under six months.
Stack. Next.js 16, Supabase (Postgres with row-level security), Vercel, Resend, Sentry, GitHub Actions, Playwright, Vitest.
Status. Live at buscoservicio.com.ar. 230+ professional profiles. Client registration opened on 8 September 2026.
The problem
In Argentina, hiring a plumber, an electrician or someone to clean your house runs on WhatsApp groups, a neighbour's recommendation, or whoever answers first. There is no shared place to see who is available, what they charge, or whether past clients were happy. You pay in cash or by transfer and hope for the best.
Two founders came to me with an idea shaped by the country's unemployment wave: a platform where tradespeople could earn money independently with their services, in the spirit of the new apps that were appearing in Argentina at the time. The first market is Greater Buenos Aires (AMBA).
The design problem underneath was trust. A stranger is going to enter your home. Money changes hands before the job. Neither side has proof of anything. Every flow in the product exists to earn that trust one step at a time.
Constraints
One person on product. Design, frontend, backend, database, deploy, content and launch marketing all went through me, while the founders ran the business. That is why the documentation is thorough: I wrote the client, professional and admin flows as documents with state diagrams before building them, because my only teammate was my own notes from a month earlier.
No payment gateway, by decision. The founders chose manual bank transfers over Mercado Pago or Stripe to avoid gateway fees. A client transfers to the platform's account, marks "I already transferred", and an admin checks the bank statement and confirms by hand. That decision shaped a whole reconciliation queue in the admin panel. A Mercado Pago integration is drafted and ready if the founders ever change their mind.
Argentine data protection law. Users have the right to have their personal data deleted. I designed an account deletion flow that anonymises personal data while preserving the transaction history the other party depends on.
Mobile-first users. Tradespeople and clients looking for a quick fix use their phones. A dialog that does not fit a small screen, or a form that loses its state on refresh, is not a polish issue. It is an abandoned booking.
Process
Before writing any code I researched services marketplaces in Argentina and abroad, built a moodboard, and shipped a standalone landing page to start capturing interested professionals while the product was still being planned. The scope then grew from a small MVP into a full platform: admin dashboard, professional and client profiles, internal chat, booking and payments, as the founders and I learned what the business needed.
I treated documentation as a design artifact. Each flow was written first as a document with a diagram of every state transition: how a booking moves from pending payment to pending validation to confirmed to completed, who triggers each step, which email fires when. Those diagrams became the spec I built against.
I worked in a pull-request-per-feature cadence: 151 merged PRs over five months, each scoped to one change. That discipline let me trust my own past work without a second engineer reviewing it.
The most consequential thing I did was a structured UX review of the live product in June 2026, run with AI agents in Claude Code. Six agents mapped the subsystems of the codebase, eight looked for UX problems, and every finding went through an independent adversarial verifier that tried to disprove it by reading the code. The result: 121 findings, 119 unique, 80 verified adversarially, 79 confirmed and 1 refuted. The 25 highest-severity findings, in four themes (a payment flow with holes, dead-end auth states, professionals operating blind, dialogs that broke on mobile) went from finding to shipped fix within days.
I would rather say plainly that this was AI-assisted than dress it up. The value was not that an AI found bugs. It was a process where every claim had to survive something trying to disprove it before I acted on it.
Solution
Search and booking with 1-hour slots
A client searches by category or free text, filters by zone, mode and rating, lands on a public profile, then picks a 1-hour slot on a calendar and sees the price before committing.
Key decision
Slots are fixed at one hour. Real jobs vary in length, but a fixed slot kept the whole flow tractable for one person to build and simple for a professional to manage.
Trade-off
For a long time the calendar did not hold a slot during payment: a client could see it free, transfer the money, and lose it to someone else booking in the gap. I flagged this in the June review and fixed it with a slot hold plus a 24-hour expiry on unpaid bookings.
Desktop
Mobile
Payment by bank transfer with admin validation
The client sees the platform's bank details, transfers the price plus a 4% fee and marks "I already transferred". An admin checks the transfer against the statement and confirms or rejects it. Confirmation is the moment the professional's contact details are released. When the job is done, the professional enters a 6-digit code the client received by email, which completes the booking and generates the payout: price minus the fee.
Key decision
The money model stays simple. The platform collects everything, there are no split payments or connected accounts, and the admin transfers the net payout afterwards.
What I changed
Early on, a client could transfer money before any booking record existed, so a paid slot could still be taken by someone else. I closed that with the slot hold, and fixed the dead ends around it: a booking stuck in pending payment with no screen showing the bank details, and a rejected-payment email that promised a refund the system did not have.
Optional identity verification and the "Verificado" badge
A professional can submit a government ID and a police background check to earn a "Verificado" badge. Without it they can still list services and get booked, with just a description and one active service.
What I changed
Verification started as a mandatory gate: no documents, no visible profile. I changed that in August 2026 after watching the onboarding campaign in practice: 27 of the first 30 professionals who started signup stopped at the document upload step. I made verification optional and turned it into an earned badge, on the reasoning that a full marketplace serves clients better than an empty one behind a wall nobody gets through. The migration that made the change records the decision and the reason in the code itself.
Trade-off
The badge now means "chose to verify", not "vetted professional". Reviews and moderation carry the rest of the trust signal.
Desktop
Mobile
Admin panel with activity log, payment queue and moderation
One panel, seven sections: dashboard, payments, payouts, professionals, clients, reviews, admins. Every action goes through a server function that re-checks the admin role, validates the input and writes to an immutable audit log. Reviews are born unapproved and need manual moderation before they show.
Key decision
I built the audit log from day one, because the panel was always going to be run by people who did not write the code. Every action needed a trail that made sense after the fact.
Trade-off
This panel is the platform's only operational interface, and every payment, approval and review passes through the founders by hand. That does not scale past a certain volume. It was the right call to get a working product out fast, and it is the first thing to change as volume grows.
Activation and communication
New professionals get a wizard signup, a waiting screen while their profile is reviewed, and 28 transactional emails covering every state change: approval, rejection, payment confirmed, code sent, payout generated. Before launch I seeded the marketplace with 214 profiles from the founders' contact lists, in three batches, so the first client would not land on an empty site. Then came three activation campaigns: eight email waves in late July to all 214, an email plus WhatsApp push in mid August when verification became optional (186 of 198 WhatsApp messages delivered), and a segmented campaign in late August with three groups: professionals who had never logged in (172), those who logged in but left the profile incomplete (23), and those with a complete profile and services (19). I also recorded 20 video tutorials on YouTube, for professionals and for clients, and produced two short reels with an AI generation pipeline at close to zero cost.
Key decision
The tutorials were recorded by running the end-to-end test specs against the real app while capturing the screen. The same automation that verifies the flows also produces the footage.
Seeded profiles are not signups, and I track the difference. Of 237 professionals today, 70 have ever logged in: 47 who claimed a seeded account and 23 who registered on their own. 34 have loaded an active service, which is the real bar for a bookable profile, and 15 carry the verified badge. The campaigns moved the number, from 30 activated after the first waves to 70, but the honest read is that a list of names is not a marketplace. Getting the other 167 to log in, or replacing them with people who want to be here, is the current job.
Desktop
Mobile
Design system and brand
I wrote a full brand book covering logo, palette (violet and amber), dark mode, typography, iconography, components and spacing, and shipped it live inside the product. The app runs on Tailwind 4 with a shadcn-style component set: the same cards, dialogs and form patterns reused across the client, professional and admin surfaces.
In July 2026 I ran a four-stage redesign of the home page and of the landing that recruits professionals: counters pulled live from the database instead of invented stats, an FAQ that answers the real onboarding questions, and a sticky mobile call to action.
Desktop
Mobile
Engineering notes
Next.js 16 on Vercel, Supabase for database and auth. The schema grew through 59 migrations, each tested locally before touching production. Row-level security is the backbone of the privacy model: a professional's phone number and address are invisible to a client until the database itself releases them, which only happens when an admin confirms the payment. That rule holds even if a frontend bug tries to show the data early.
Booking state transitions are enforced in Postgres triggers, so a booking cannot jump from pending to completed without the right role. Resend handles email. Sentry handles monitoring, including the daily cron jobs, so a silent failure does not go unnoticed. Production deploys run from the main branch through GitHub Actions. Tests split between Playwright for end-to-end flows and Vitest for units.
The hardest call
At one point the product was in good shape and I still wanted to keep improving it: more fixes, more polish, more features. But the platform had almost no clients and not enough professionals getting booked. It did not need more product work. It needed marketing: getting the word out, bringing in clients and professionals, making the platform earn money.
I told the founders directly: stop funding product for a while and put that money and time into marketing instead. It is not the easy thing to say when you would rather keep building. But a marketplace with nobody on either side is not a product problem, it is a demand problem, and no amount of polish fixes that. They agreed, and that is why I spent the following weeks on campaigns, tutorials and reels instead of another feature.
Impact
As of 25 September 2026: 237 professional profiles, 234 publicly listed, 70 activated by their owners, 34 with an active service, 15 with the "Verificado" badge. 76 services across 16 categories. Zero paid acquisition: every number came from seeding, three campaigns by email and WhatsApp, and word of mouth.
Client registration was behind a "coming soon" screen until 8 September 2026. At the time of writing there are no completed bookings yet. All test transactions were purged from production on 24 July as a pre-launch cleanup, so today's zero is a fresh start, not a broken product. The traction that is real today is on the supply side and in the activation machinery. The demand side is just getting started, and I will update this page as it moves.
On process: 151 merged pull requests, 214 commits, 59 migrations, 28 transactional emails, 20 tutorials, 2 reels, one person.
What I would do differently
Make verification optional from day one. The mandatory gate cost real signups before I changed it. It felt like the responsible default for in-home services, but the campaign data showed that a strict gate with no visible marketplace behind it kills onboarding instead of building trust.
Push earlier to reduce manual payment validation. Even within the founders' no-gateway decision, I would raise the scaling problem before opening client registration, not after. The Mercado Pago plan is drafted for when they want it.
Seed less, activate more. Seeding 214 profiles made the site look full on day one, but 167 of those people have never logged in. A smaller list of professionals who actually want to be there, activated one by one, would have been a stronger base than a big list of names.
Keep test data and real usage separate from the start. Needing an audit and purge script right before launch, to confirm that every transactional row in production was test data, told me I should have separated the two environments cleanly from day one.
Team
Me, founding designer, product end to end: research, brand, UX, frontend, backend, launch, campaigns. Two founders who run operations, recruit professionals and validate payments.
