Field-Service Operations Product & Marketing Site

A technical-assistance and repair business needed the system that runs its service orders end to end — from the moment a customer walks in with a broken thing to the moment the invoice is settled. Eight desktop modules, a deliberately small mobile surface, and the marketing site that sells the whole thing.

Agency work at Spaceapps; the client relationship belonged to the agency and I delivered as staff. The discovery was run by the tech lead, who handed me the board. From that board onward the product design was mine, alone — and the landing page was mine to design and to build.

Front desk to money

A repair shop's real problem is not any single screen; it is that a device, a promise and an amount of money travel through the business at different speeds and in different people's heads. The front desk takes the device in. Somebody quotes it. Somebody else fixes it. Someone has to know, three days later, where it is and what was agreed. The system had to hold all of that in one place without turning the counter into a data-entry job.

• Authentication — the way in, and the only module that exists on every surface.
• Service desk — intake and quoting, where the promise to the customer is made.
• Assistance — the work itself, with a work-order kanban so the shop can see the queue rather than remember it.
• Services and Products — the catalogues that make a quote repeatable instead of improvised.
• Customers — the history that makes the second visit easier than the first.
• Finance — quoting through to settlement.
• Configuration — the settings that let one design fit shops that do not work identically.

🧩8

desktop modules designed

📱2

of them on mobile, deliberately

🔐26

view/edit permissions, 8 areas

📁59

files in the landing-page repo

The mobile surface is two modules, and that is the design decision

The phone gets authentication and service intake. Nothing else. Not because the rest was cut for time, but because intake is the part that happens away from the desk — someone standing at a counter or in the field with a customer in front of them — and the back office is not. Finance on a phone would be a feature nobody opens. This is the opposite of a responsive-coverage claim: two of eight is the answer, and mirroring all eight onto a small screen would have been the easier and worse decision.

The money path is invoicing, not checkout

It is worth naming precisely, because the wrong word here would flatter the work and misdescribe it. There is no cart, no checkout and no recurring commerce in this product. What there is: a quote that becomes an agreement, and financial control that follows it to settlement. That is business-to-business invoicing, and designing it well is a different problem from designing a store — the hard part is not payment, it is that the amount can change between the promise and the repair.

Permissions are a module, not three hardcoded screens

Discovery modelled three actors, and the obvious way to design for them is to draw three versions of every screen. I did the opposite. Access lives in Configuration as its own module: a profiles table — Admin master, Técnico, Vendedor — each showing how many users sit in it and whether it is active, and a profile builder holding roughly twenty-six individual permissions across eight areas of the product, every one of them split into view and edit. Ver financeiro and Editar financeiro are separate switches, and so are the kanban, the work orders, the parts orders and the reports. The shop can then define a profile I never thought of, which a shop with a night-shift technician will need and I could not have guessed.

The landing page

The marketing site was mine to design and to build, in Next.js: hero, banner, a how-it-works section, two feature-image sections, testimonials, an FAQ and a closing call to action, plus the cookies, privacy and terms set and a custom 404. At fifty-nine files it is the leanest repository of that period, and lean was the point — a marketing page for an operations product should load instantly on the worst connection in the shop.

What this is not

• Not my build of the product. I designed it; a Bubble developer built it and a later developer rebuilt it in Next.js.
• Not evidence of my engineering. The live application evidences my design, and the fact that the design survived a rewrite. The code behind that login screen has never been mine.
• Not the discovery. The tech lead ran it and handed over the board.
• Not a responsive-coverage claim. Two of eight modules exist on mobile, deliberately.
• Not proof that the other seven modules each render differently per profile. Access is specified in Configuration rather than drawn as per-role variants of every screen, so those variants do not exist in the file and I do not claim them.
• Not payments or checkout. Quoting plus financial control is invoicing.
• Not a date range for the engagement. The dates on this page bound the landing-page repository only — the product design came before it, and version control cannot date that.
• Not the site at the product's own address today. That is someone else's redesign at the address my page used to occupy.

The design outlived its own implementation

The most useful thing this project proves is not that it shipped. It is that when the application was rebuilt from scratch on a completely different stack, by a developer I never worked with, the design went across. Nobody redesigned it on the way. That is the closest thing a designer gets to a load test: the interface was specified clearly enough that a stranger could rebuild the thing underneath it and leave it standing.

Evidence

The product is live and running a real business today: anyone can reach the login screen. It evidences the design and not the engineering — the application was built in Bubble by another developer and later rebuilt in Next.js by an incoming one, and the design came through that platform rewrite intact, which is a harder test than shipping once. The landing page I built no longer exists at its original address; it was replaced by someone else's redesign after I left, so the copy on my own domain is the only surviving artifact of it, and it is a copy rather than the instance that served the client. No performance metric exists for this project — a confirmed absence, not an uncollected one.