Contractors lose time juggling apps. Floorix connects the whole job.
Customer details, estimates, contracts, crews, photos and invoices often live in different places. Floorix brings them into one connected workflow. Create the estimate, then carry the same job forward into contract, project, crew and invoice without re-entering the same information.
The work was not the problem. The disconnected admin around it was.
Contractors were moving the same job information between calls, texts, paper estimates, spreadsheets and separate documents. Floorix was designed to remove those repeated handoffs: collect the customer once, build the estimate once, and let the same information continue through the rest of the job.
The same job was rebuilt again and again.
Customer details in calls and texts, an estimate in one place, crew hours somewhere else, photos in a camera roll, and invoices built separately.
Create the estimate. Keep the workflow moving.
Customer information stays attached as the job moves into the contract, project, crew workflow and invoice instead of being re-entered at every step.
Give each person only the part they need.
Owners get the whole job. Crews get a focused phone experience. Clients open simple links for intake, review and signature without creating an account.
At a glance
Work was fragmented
Client details, estimates, crew time, job photos and invoices lived in separate tools and conversations.
5 workflow interviews
Three contractors, one subcontractor and one customer exposed the handoffs creating the most friction.
Customer-first for owners, task-first for crews
I reduced top-level complexity, made the customer profile the hub, and gave subcontractors a focused field UI.
Live pilot
10 contractors and about 20 subcontractors are testing the product; pilot feedback has already driven interface changes.
The job is simple. The paperwork around it is not.
A flooring job passes through at least four people and six documents: a lead calls, the contractor measures and quotes, the homeowner approves, a crew installs, someone proves the hours and photos, and finally an invoice goes out. Each hand-off is a text message or a phone call.
When something slips (a missed approval, an unlogged hour, a photo nobody can find), it costs the contractor money or trust. The people absorbing that friction are owner-operators who are on a job site, not at a desk.
How it shows up in the field
- Leads and customer details scattered across calls, texts and notes
- Estimates drafted on paper or in spreadsheets, retyped into contracts
- Approval chased by text; no clear record of who agreed to what
- Crew hours reported from memory; no proof of where or when
- Job photos and site notes buried in group chats
- Invoices built separately, numbered by hand, sent as screenshots
Design brief
For the owner
See every customer, job and dollar in one place, and send a professional estimate in minutes instead of an evening.
For the crew
Clock in, add a photo, leave a note: one thumb, one screen, no training, on a phone with dusty hands.
For the homeowner
Review an estimate, sign a contract and see an invoice from a text link, with nothing to install and nothing to remember.
Start in the field, not in the feature list.
The research was direct conversation, not a survey. I spoke with the people at each end of a flooring job (contractors, a subcontractor and a customer) and listened for where the phone calls, texts and manual handoffs were doing work the software should do.
interviews across the flooring workflow
Three contractors (one also an industry advisor), one customer and one subcontractor.
How project information, estimates, labor, contracts and communication move between people, and where it breaks.
What I heard, and what I designed
Marcus
“During the design process, I have to spend a lot of time with clients on the phone. Could we have a link we send to the client so their information comes directly into the portal?”
Pain point. Client requirements were collected by phone, adding work and scattering the information.
Opportunity. Let contractors send customers a structured intake link.
What I designed. A client intake form the customer completes themselves; submissions land in the contractor workspace.
Aaron
“Sometimes I can’t accurately track subcontractors’ time. It becomes a manual process of asking them how many hours they worked.”
Pain point. Hours were self-reported and reconstructed later by calls or messages.
Opportunity. A simple way for subs to record work time inside the project workflow.
What I designed. Labor tracking with one-tap clock-in and clock-out tied to the project.
Daniel
“Turning an estimate into a contract is one of the most useful parts. Being able to send the client a link for an online signature makes it even better.”
Pain point. Moving from approved estimate to signed agreement meant extra manual steps and disconnected tools.
Opportunity. Keep estimate, contract and signature in one workflow.
What I designed. Estimate-to-contract conversion with a shareable link for online signature.
Elena
“The client intake form is very useful. I can enter the information myself, especially details that can be complicated to explain over a phone call, and I now have a record of what I requested.”
Pain point. Detailed requirements are hard to explain verbally, and customers have no record afterwards.
Opportunity. Give customers control over how they communicate requirements.
What I designed. A structured intake form that also creates a written record for both sides.
Noah
“Being able to navigate directly to the job address and see only the information I need is very helpful. I can also upload project pictures and keep relevant messages with the job.”
Pain point. Crews waste time hunting through messages for addresses, instructions and photos.
Opportunity. A focused field experience with only the assigned work.
What I designed. A project-focused field view with the job address and navigation, photo upload, and notes kept with the job.
Four research themes
Reduce phone-dependent workflows
Contractors and customers needed a structured way to exchange project information without lengthy calls.
One source of project information
Requirements, labor hours, estimates, contracts, photos and messages needed to stay connected to the project.
Remove manual handoffs
Work should continue naturally from intake → estimate → contract → signature → project execution.
Simplify the field experience
Subcontractors needed the job address, assigned details, relevant communication and photo upload, without the full contractor system.
These themes directly shaped the client intake, labor tracking, estimate-to-contract, online signature, field project view, navigation, photo uploads and project messaging workflows.
Competitive positioning
Horizontal field-service tools
Strong scheduling and dispatch, built for many trades. Heavy to learn, priced for larger teams, and generic about the details that matter in flooring.
Floorix's wedge
Vertical depth over breadth: flooring vocabulary in the estimate, crew-first mobile screens, client-friendly links, and a setup an owner-operator can finish before lunch.
Three people, three very different screens.
The product has one data model but three experiences. Each is designed around where the person is standing and how much attention they have.
The owner-operator
Master roleDesktop + phoneGoals
Quote fast, win the job, keep the crew moving and get paid on time.
Frustrations
Admin eats evenings. Information lives in too many places and nothing gives a clear picture of the business.
Design response
A dashboard that answers “how's the business?” at a glance, and a customer profile that answers “where does this job stand?”
The subcontractor
Sub rolePhone onlyGoals
Know the job, clock in, show the work, get on with it.
Frustrations
Dust, gloves, bad signal. Anything that takes more than a couple of taps gets skipped.
Design response
A mobile-first portal with large targets, a single obvious Clock In, and photos and notes attached right on the job card.
The homeowner
No accountOpens a linkGoals
Understand the price, feel confident, say yes, and know what to pay and when.
Frustrations
Unclear quotes, software they don't want to sign up for, and not knowing if a document is legitimate.
Design response
Clean, branded, read-only pages reached from a text or email link, with a clear estimate disclaimer and a deliberate signing step.
Roles and access
Roles are assigned on the server, never taken from the sign-up form. An owner invites a subcontractor by email; the account is created with the sub role and tied to the owner's company, so crews only ever see the jobs assigned to them.
Six rules the interface is held to.
Compact, warm and operational
Dense enough to scan like a work tool, warm enough to feel like a trade, cream surfaces, warm borders, gold actions.
The customer is the spine
Every estimate, contract, project and invoice hangs off a customer, so the answer to “what's going on with this client?” is one tap away.
One thumb in the field
Crew screens use big targets and a single primary action. If it needs two hands, it's the wrong screen.
Clients never need an account
Anything a homeowner must see or sign opens from a link and works on any phone, with no install and no password.
Gold means act, green means money
One accent for actions, one for value and success. Status is always a labelled pill, never colour alone.
Safe by default
Roles, company boundaries and public links are enforced on the server, so the UI can stay simple without being fragile.
Six flows that carry a job from inquiry to payment.
I mapped the system before drawing screens. These diagrams are drawn from the shipped product, so they show what the app actually does, including where a step happens on the server, not on screen.
1 · How everything connects
The data model is the first design decision. A company owns customers; each customer owns estimates, projects and invoices; each project collects photos, notes and labor logs. An approved estimate creates a project automatically.
2 · Account setup and crew access
Sign-up is deliberately short. Everything privileged (the company, the owner role, the subcontractor role) is created by the server, so nothing a user types can grant itself access.
3 · Customer intake
Owners can share a public form so a new client enters their own details. Submissions wait in a pending list, so nothing lands in the customer directory until the owner approves it.
4 · Estimate to contract to project
This is the revenue path. The estimate is shared as a link, the contract is signed by both parties on a dedicated page, and a project is created automatically once the estimate is approved, no re-entry.
5 · Invoicing
Invoices are numbered per company by the database, so two owners never collide and the same owner never skips a number. The share link is generated only when an invoice is marked sent.
6 · Field work
The crew's job is intentionally tiny: clock in, add a photo or note, clock out. Everything else (the live session, the saved photos, the labor log and what the owner sees) is the system doing the bookkeeping.
Navigation structure
Desktop · owner
Top tabs keep the whole business one click away.
DashboardProjectsCustomersEstimatesContractsInvoicesTeamLaborCustomer profile, edit-project and company settings open as modals, so context is never lost.
Mobile · owner and crew
Five bottom tabs. Everything else lives in a “More” sheet.
HomeClientsTeamLaborMoreProjects, estimates, invoices and settings sit in the sheet, keeping the bar short enough to hit with a thumb.
Compact, warm and operational.
The system was built to look like the trade it serves: honest materials, warm neutrals and a single gold accent, and to stay compact, because the people using it are busy.
Colour
Typography
Cormorant Garamond for titles and numbers, a refined serif that gives money and headings weight.
Outfit for everything operational, friendly geometric sans, legible at 11px in dense tables and on phones.
Components
Four intents only: primary (gold), secondary (outline), success (green), danger (red). Each has default, hover and disabled states.
Always a word, never just a colour: Active, Approved, Draft, Sent, Paid, Void. Dollar values are always green serif.
14px radius, a hairline warm border, and 38–42px fields on a cream fill so inputs read as inputs on white cards.
Tokens
| Token | Value | Used for |
|---|---|---|
| Radius | 14 / 10 / 7 px · pill 999 | Cards and modals / controls / chips |
| Border | amber at 15% and 26% opacity | Warm hairlines instead of grey |
| Shadow | soft black + amber tint | Warm lift on modals and device frames |
| Touch target | 44 px minimum | All crew and client screens |
| Breakpoints | 768 px mobile switch | Top tabs → bottom tab bar |
The owner's workspace.
Every screen an owner works in, from the dashboard to the invoice.
Dashboard
Projects
Project detail
Edit project
Customers
Customer profile
Estimate editor
Invoices
Team
Labor logs
Estimates list
Review a new client
Company settings
Crews and clients, on their phones.
Mobile is not a shrunken desktop. The bottom bar, big targets and one-primary-action screens are designed for a person standing in a house with a phone in one hand.
Seven decisions, and what each one cost.
Make the customer profile the hub
- Problem
- Estimates, contracts, projects and invoices were separate lists. To answer “where does Jane's job stand?” the owner had to visit four tabs.
- Decision
- One customer profile modal that gathers every record for that customer, each with its own next action (Add Estimate, Create Project, View Invoices).
- Why
- It matches how owners think in customers, not tables, and it keeps them in context because it's a modal over the list.
- Trade-off
- A long modal gets heavy for customers with many jobs. Next step: collapsible sections and a recent-activity strip.
Five tabs and a More sheet on mobile
- Problem
- The desktop has eight top tabs. A phone can't.
- Decision
- Home, Clients, Team, Labor and More. Projects, estimates, invoices and settings live in the sheet.
- Why
- The five most-used destinations stay one tap away, and the bar stays within thumb reach.
- Trade-off
- Projects sit one level deeper than I'd like. If usage data shows it's a daily destination, it earns a tab.
Clock-in never waits on GPS
- Problem
- Contractors asked for geofencing, a fence that blocks clock-in outside the job site. But GPS is unreliable on job sites: basements, new construction and rural areas have weak or no signal, and permission can be denied by mistake. A blocked button means a crew member who doesn't bother.
- Decision
- I chose not to make geofencing a hard blocker. GPS can be unavailable or imprecise on job sites, so Floorix starts the shift immediately and records location as supporting evidence when permission and signal are available. Location is captured at clock-in and again at clock-out.
- Why
- The time record is the priority; GPS is evidence, not a gate. The Active Shift screen shows a green “GPS recorded” confirmation when it lands.
- Trade-off
- A shift can exist without a location. Owners see missing GPS clearly in the Labor log rather than the sub being blocked.
Clients use links, not accounts
- Problem
- Homeowners hire a contractor once. Asking them to sign up for software is a conversion killer.
- Decision
- Estimates, contracts and invoices each open from a unique token link, and the server hands back only that one document.
- Why
- It removes friction at the exact moment the contractor needs a yes.
- Trade-off
- Links can be forwarded. Mitigation: tokens are unique per document, and invoice links are only created when an invoice is marked sent.
Make signing a deliberate act
- Problem
- A contract that's too easy to sign feels meaningless; one that's too hard never gets signed.
- Decision
- Show the payment schedule and terms first, then ask for a typed name, initials and an explicit consent checkbox. Both signatures and timestamps appear on the document.
- Why
- It feels serious without feeling legal. The default 60 / 30 / 10 schedule is visible before the client commits.
- Trade-off
- Typed signatures are lighter than a full e-signature product. Right for residential jobs; bigger contracts may need more.
Let the server be the safety net
- Problem
- A solo-built, multi-tenant app handling customer data can't rely on the interface to enforce who sees what.
- Decision
- Company boundaries, roles and public-link access are enforced in the database with row-level security and token-based functions, and later hardened with tests for concurrent invoice numbering and signup provisioning.
- Why
- It lets the UI stay simple. No client-side role switches.
- Trade-off
- Debugging permission issues takes more care. The payoff is a UX that doesn't need defensive complexity.
Defer in-app payments until the infrastructure is ready
- Problem
- Contractors wanted clients to be able to pay directly through Floorix.
- Decision
- I intentionally deferred payment processing. Flooring invoices can involve large transactions, and taking custody of payments would introduce operational, security and support requirements that the early product was not ready to own. Instead, each contractor saves their preferred payment instructions once and Floorix places them on every invoice.
- Why
- The immediate user need was a clear, repeatable path to getting paid. Supporting the contractor's existing payment methods solved that need while keeping the product focused on the workflow it could support reliably.
- Trade-off
- Floorix cannot automatically confirm payment, so the contractor marks an invoice as paid. Integrated payments remain a later product decision once the required infrastructure and controls are in place.
Continuous improvement
I do not treat a shipped screen as a finished answer. Products change as real people use them, new constraints appear, and small points of friction become visible. My approach is to keep the core workflow simple, listen closely to feedback, measure what is actually happening, and improve the product without adding complexity for its own sake.
“Good product design is never finished. It gets clearer each time real users show you where the friction still lives.”
My product design principle