
Role: Solo Designer and Researcher
Timeline: Late 2024 to Mid 2025
Tools: Figma, N8N, Supabase, Claude, Twilio
Type: Self-initiated personal project
I have been real estate adjacent my entire life. When I relocated to Puerto Rico 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. An actual gap I could see with my own eyes.
Property management in Puerto Rico was the obvious place to look. It runs on memory, scattered WhatsApp threads, and informal relationships built over years. There is no single source of truth, just experienced people holding everything together in their heads.
I built Arca to change that. If a system could automatically capture unstructured requests, organize them intelligently, and surface vendor recommendations based on real signals rather than memory, any team member could make a good decision. Not just the most experienced one.



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.
Property management runs on memory, scattered WhatsApp threads, and informal relationships. There is no single source of truth just experienced people holding everything together in their heads.
This creates real problems at every level.
Requests fall through the cracks. Vendors get chosen based on who you called last time, not who actually performs best. When the most experienced person is unavailable, decisions stall or get made poorly. And as a portfolio grows, the system doesn't scale. It breaks.
If a platform 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 and give property managers something they have never had before. Visibility, accountability, and a system that scales with them instead of breaking down under pressure.
.png)


Arca is an AI-augmented property management dashboard built around four core components.
1. Automated Ticket Ingestion
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 intent: Zero behavior change required from tenants or the team. The system works with how people already communicate. It just brings structure to what was previously unstructured.
2. Centralized Operations Dashboard
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.
3. AI-Powered Vendor Recommendation Engine
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.
4. Conversational Interface
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.
If Arca were to move into a full development cycle, these are the design priorities that would define the next phase.
The first and most critical step would be running usability testing with actual property managers to validate the information hierarchy and measure how much users trust the vendor recommendations. Trust is the hardest problem in AI design and the only way to know if the interface earns it is to observe real users interacting with it under real conditions.
Mobile responsiveness would be a close second priority. Property managers are not sitting at desks. They are walking units, meeting vendors on site, and making decisions in the field. A mobile experience designed around those moments is not optional. It is fundamental to how this product would actually get used.
On the AI side the recommendation engine would benefit from richer signals. Layering in real time provider availability, pricing estimates, and historical response times would produce more accurate recommendations and give users more concrete reasons to trust the output.
As the user base grew the product would need to scale beyond single properties. A multi portfolio view for managers overseeing buildings across different markets would introduce an entirely new layer of design complexity around hierarchy, context switching, and data aggregation worth exploring.
Finally a feedback loop allowing managers to rate vendor recommendations would close the gap between AI output and real world outcomes making the system smarter and 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 observed closely for years.
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 design problem I find most interesting. And it is exactly the kind of problem I want to keep solving.