back
OICO
The product had market fit and serious funding. It also ran on people doing by hand what it claimed to automate.
Role
Lead Product Designer
Team
+1 Product designer
2 Product managers
8+ Developers
Period
04/2022 to 05/2023
About the company
Oico built a B2B construction-materials marketplace connecting builders, stores, and deliveries in Brazil, turning a manual, service-based operation into a product built to scale. Backed by Y Combinator, Valor Capital, and Tiger Global.
—
Tags
I joined Oico as Lead Product Designer, part of a senior product team. A Y Combinator company that had just raised a US$5.5M seed led by Valor Capital, with Tiger Global. A B2B marketplace for construction materials, connecting builders, stores, and deliveries, with clients that included names like Loft, Blink, and Reformei. Product-market fit was real. Paying customers were real. But the product was a shell that worked because people made it work, and my job was to lead the design that turned that shell into something that could scale.
The problem
Brazil's construction sector runs on paper, WhatsApp, and memory. And its language is deliberately imprecise.
The same order means different things to different people
A "Bahian brick" in São Paulo is a "mineiro brick" in Rio. A "cement bag" is 25kg or 50kg depending on the supplier. A foreman orders "that iron" and expects the store to know the gauge from context.
Before Oico, every request passed through three or four people interpreting WhatsApp messages before it became a real purchase.
Forcing 50,000+ independent suppliers to standardize their terms would break decades of practice and lose users on day one. But without structure, every order was a guessing game. The company had grown by starting as a service, doing everything manually, and it was now trying to become a product. When I arrived, it was stuck between the two: the operation worked, but the software was mostly a transmission line. People did the real work.
The order that showed the whole problem
A builder sends "500 Bahian bricks for tomorrow." CS asks if they mean the nine-hole ones. The builder confirms. CS creates the order, the store replies they only have the six-hole version, CS checks back, the builder adjusts the quantity, the store questions the cement spec, another round of calls.
Four hours, six people, and plenty of room to get it wrong.
The errors almost always started at the very first message. "Bahian bricks," but six holes or nine? Red or white? The product never asked. So that became the design principle: make the product ask the questions, instead of the CS team. Move the interpreting out of people's heads and into the system.
What I built
The direction came from product, design, and engineering working together. My part was maturing the design foundation so it could carry scale. The system I inherited was built for an MVP: simple forms that worked because a CS person caught whatever they missed. For the product to ask the right questions on its own, without that person, the forms needed more structure, validation, states, room for redundancy. I restructured the components and form patterns to hold that weight, and designed the flows on top of them. Two moves mattered most.
The system reads the order and asks the right question
Instead of a person interpreting "500 Bahian bricks," the product mapped it to a specific SKU based on region and past purchases, then confirmed in plain language: "500 nine-hole ceramic bricks, 14x19x19cm, correct?" One tap. What took hours took seconds, and every correction taught the system to guess better next time.
CS intervention:
100% to
13% of orders
The team stopped reviewing everything and started handling only the cases that actually needed a human
01.
Our AI-assisted purchasing system can read any service order document and generate a shopping list with associated products registered by our sellers.
02.
Store view.
Recurring orders became one tap
For the materials a builder bought every week, the product surfaced "your usual cement, 10 bags, R$280" instead of making them rebuild the list from scratch. Routine buying stopped being manual work.
Around these, I designed the structured views the rest of the chain needed: stores receiving clean, specified orders instead of vague WhatsApp messages, drivers seeing their day and routing in one tap. The point throughout was the same, take the ambiguity off the people and give it to the system.
01.
Above are the post-login home screen for buyers and the product showcase for sellers.
02.
Checkout.
03.
Routing app for both in-house and third-party delivery drivers.
Results
The same CS team handled far more volume without growing, because the product finally did the work instead of transmitting it. A foreman could order in the morning and have materials on site by afternoon, which in construction is the difference between a working day and a stopped one.
4h to 15min
Order processing time
100% to 13%
Of orders needing CS intervention
7x
More orders handled by the same team
85%
Reduction in manual work
What I learned
This one pulled together what the others taught me. In construction, as in nonprofit fundraising and rental guarantees before it, the instinct is to fix chaos by imposing a standard. It never works, because people have decades of reasons for doing things their way. What works is building a system that absorbs the ambiguity and gets smarter with use, meeting people where they are and quietly moving the structure into the product, not onto the user. And this one taught me a sharper version of it: a system can only absorb complexity if its foundation is built to hold it. After four products in messy, high-variability sectors, that's the pattern I trust most.
