Role: Solo Designer and Researcher
Type: Self-Initiated Personal Project
Year: 2025
Tools: Figma, N8N
Status: Functional prototype, design validated
I have been real estate adjacent my entire life. My mom is in real estate. I grew up around it. When I relocated to Puerto Rico in 2025 I was surrounded by it again, but this time I was also deep into learning AI product design through certifications, coursework, and a lot of self-directed building.
I wanted to practice on a real problem. Not a prompt someone handed me, not a redesign exercise. An actual gap I could see with my own eyes.
Puerto Rico was the obvious place to start looking.
Property management in markets like Puerto Rico runs almost entirely on informal communication. Maintenance requests come in through WhatsApp, text, and email. There is no central system. No audit trail. No structure.
Vendor selection is even harder. Most property managers rely entirely on whoever has been doing this the longest. A mental rolodex built over years of relationships. If that person is not available, decisions stall or get made badly.
I wanted to know if this was just my observation or something more systemic. So I talked to people.
I had informal discovery conversations with property managers across two markets, Puerto Rico and New York, drawing on relationships I already had in both circles.
This was not a formal research study. It was real conversations with people doing this work every day, asking them where things consistently break down.
What I kept hearing:
"Everything comes through WhatsApp. I have to scroll back through months of messages to find anything."
"I know who to call because I have been doing this for years. My team does not always know."
"Finding a good plumber is not the problem. Knowing which plumber for which job, for which building, at what price, that is the problem."
"If I am not available, things fall through the cracks."
The bottleneck was not the work itself. It was the coordination and decision-making layer, and that layer lived entirely inside a few people's heads.
What if the expertise did not have to live in one person?
If a system could automatically capture unstructured requests, organize them intelligently, and surface vendor recommendations based on real signals rather than memory and relationships, any team member could make a good decision. Not just the most experienced one.
That became the design opportunity: use AI to democratize expert judgment.
.png)
The problem: Maintenance requests arrive through WhatsApp, text, and email and never get formally logged anywhere.
What I designed: An agentic workflow built in N8N that monitors incoming messages across channels, extracts the relevant information, and automatically creates a structured maintenance ticket in the dashboard. Each ticket is categorized, timestamped, and assigned to the correct property.
The problem: Property managers have no single view of what is happening across their portfolio at any given moment.
What I designed: A unified dashboard showing active maintenance tickets, ticket status, occupancy overview, and priority flags together in one view. The information hierarchy was designed around the questions a property manager actually asks at the start of their day. What needs my attention right now? What is unresolved? What is coming up?
Key decisions:
Tickets are organized by urgency and age, not just the order they arrived. Occupancy and maintenance are visible together because they directly affect each other. Status indicators were designed to be scannable without requiring any clicks to understand what is happening.
The problem: Vendor selection depends entirely on institutional knowledge that lives in one person's head and nowhere else.
What I designed: When a maintenance ticket is opened, the system analyzes three signals to recommend the best service provider for that specific job. Unit history, meaning what issues has this unit had before and who resolved them well. Ticket patterns, meaning what type of work is this and who specializes in it. And provider reviews, meaning what is this provider's track record for similar jobs nearby.
The recommendation surfaces with its reasoning visible, not just a name. That was a deliberate decision. A recommendation without context is not trustworthy, especially for someone who is newer to the team. Showing the rationale builds confidence and over time builds capability.
The problem: Not everyone on the team knows how to navigate a dashboard or interpret operational data.
What I designed: A chat interface that lets property managers ask questions in plain language. Something like "Who should I call for an HVAC issue in unit 4B?" and receive a contextualized, reasoned answer back.
The intent: Lower the floor for less experienced team members. If the expertise is embedded in the system, the interface should make it accessible to anyone, not only the person who spent years building that knowledge manually.
Why surface the reasoning behind a recommendation rather than just the answer?
Trust is built incrementally. A team member who can see why a vendor is being recommended starts developing their own judgment over time. A black box answer creates dependency on the tool. A transparent recommendation builds the person using it.
Why a dashboard and not a mobile app?
Property managers doing coordination work are at a desk. A dashboard gave me the surface area to display parallel workflows, multiple tickets, multiple properties, multiple statuses, without forcing the user into a navigation-heavy mobile experience that would have hidden too much.
Why a conversational interface alongside a dashboard?
Some decisions happen inside the dashboard during a focused work session. Others happen mid-conversation, on a call, walking a property, or responding to a tenant in the moment. The chat interface meets users where they are without requiring them to stop and formally open a tool.
Run usability testing with actual property managers to validate the information hierarchy and measure how much users trust the vendor recommendations.
Design mobile-responsive views to support on-site property walkthroughs and field decisions.
Expand the recommendation signals to include real-time provider availability, pricing estimates, and historical response times.
Build a multi-portfolio view for property managers overseeing more than one building across different markets.
Design a feedback loop that lets managers rate recommendations so the system gets more accurate over time.
I built Arca because I wanted to practice AI product design on a problem I actually understood. This was not an exercise someone assigned me. It came from real conversations with real people doing work I had watched up close for most of my life.
The question I kept returning to throughout the entire process was simple: will this person trust what the system is telling them?
That question drove every decision, from making recommendation rationale visible to designing a conversational entry point to the way ticket status is displayed on the main view. Designing for AI is not just about what a system is technically capable of doing. It is about whether the person using it feels informed, in control, and confident enough to act on what they are seeing.
That is the problem space I want to keep working in.
