Built for the manager who can't be on-site

LotIQ is a mobile parking enforcement app for commercial property managers. Not lot attendants. Not a security desk. The person it's built for, call him Michael, is a 42-year-old property manager with fifteen years of experience, three or four mixed-use properties, and fifteen to thirty tenants at each one. He's almost never physically in a parking lot. He's in meetings, at his desk, handling maintenance calls, and checking his phone in between.

Parking is his most time-consuming problem. He has no remote visibility into what's happening across his lots. When a towing complaint comes in, he has no evidence to show the tenant. His enforcement staff costs him between $38,000 and $48,000 a year per person. And tenant communication about parking issues happens through fragmented channels  text, email, phone, none of it logged.

This was a self-directed design exercise built on a real product brief. My mentor, who built and launched LotIQ gave me the research foundation and coached me through the process. I made all the design decisions: information architecture, property hub structure, onboarding flow, design system, and working prototype.

Michael doesn't need a parking camera system. He needs a way to manage parking as a business problem remotely, across multiple properties, with evidence he can act on and show tenants.

Three needs consistently go underserved by existing tools.

He needs to read across all his properties at once, not one at a time.

Most parking enforcement tools are built property-by-property. That's fine if you manage one lot. Michael manages three or four simultaneously. A single-property view forces him to exit, switch context, and re-enter for each one the exact cognitive overhead his day is already full of. He needs one screen that shows him everything, ranked by urgency.

He needs to start his day in control, not in reaction.

Michael checks his phone first thing in the morning, often before he's near any property. If the first thing he sees is a live list of active violations, he's immediately in firefighting mode before he knows whether anything actually needs his attention. What he needs is a summary: what happened yesterday, how it resolved, and whether today is looking normal. Two minutes to triage, not two hours of anxiety.

He needs evidence before he acts - and a record after.

Towing a car is a high-stakes decision. Tenants push back. Without a timestamped photo, a camera source, and an audit trail he can show someone, Michael has no defensible position. Every action he takes needs to be logged automatically - not because he filled something in, but because the system did it for him.

Four choices defined the architecture. Each one is a response to a specific thing Michael's current tools get wrong.

Decision 4

Stepped onboarding with transparent pricing

LotIQ is a B2B product. Michael is not a consumer signing up for a trial, he's a property manager evaluating a business tool. Structured, progressive onboarding is standard at this tier and expected.

The setup is genuinely complex: he needs to configure parking zones, assign spots to tenants, connect cameras, and register a towing partner before the app can do anything useful. Dropping all of that on one screen would cause abandonment. The stepped onboarding walks him through each piece sequentially in ten steps, with each completed step building a clearer picture of his configured system.

The pricing screen sits inside onboarding itself, calculated in real time from his actual lot size and exit count, not a fixed plan page he finds later. He sees his monthly cost, understands the formula, and can run the ROI math himself against his current enforcement staff cost ($38,000–$48,000 per year per person) before he commits. That transparency is the trust mechanism, not a trial button, not a "contact sales" wall.

Business rationale: a fully configured account on day one drives retention. Pricing shown inside the process prevents sticker shock after commitment.

The app ships as four core tabs, a complete onboarding flow, and a set of supporting screens — a full working system, not a core-loop prototype.

Onboarding — ten-step setup flow

"Smart parking enforcement in minutes." Clear value statement before asking anything.

Name, email, password, phone.

Six-digit code input.

Property name, address, lot name, spaces, and optional lot map upload — combined into one step.

Zone definition and spot-to-tenant assignment on the same screen.

Business name, contact, phone, email. Multiple tenants from one screen.

Camera name and zone assignment.

Company name, phone, dispatch contact.

Violation alerts, peak congestion, daily summary, tenant notifications.

Full summary of everything configured.

Plan summary with pricing calculated from actual lot size and exit count. 14-day free trial.

Setup complete. Go to Dashboard.

V1 is a complete, working prototype. Two directions are next in development.

Reporting surface

Michael doesn't just manage violations, he reports up to ownership. A monthly operating cost view (enforcement activity, tow volume, cost-per-incident vs. staffing baseline) would give him something to bring to those conversations. That's the next major surface.

Desktop portal for multi-property overview

The mobile app handles day-to-day enforcement. But portfolio-level review comparing performance across multiple properties over time, may work better on a larger screen. A lightweight desktop view for ownership presentations is under consideration.

The hardest thing about designing LotIQ wasn't the complexity of the system, it was resisting the urge to simplify it for the wrong reasons.

Every instinct said to make onboarding shorter. But Michael isn't a consumer. He's a property manager who needs his lot configured correctly before the app can do anything useful. Shortening setup for the sake of it would have meant an app that felt easy to start and useless to run. The right move was to make the complexity navigable, not to pretend it wasn't there.

The same instinct showed up in the home screen decision. It would have been easier to open to the incident list, that's the "active" view, the one that feels like something's happening. But Michael doesn't need more things happening. He needs to know whether anything requires his attention right now. That's a different design question than "what's active," and it took sitting with the persona for a while to feel the difference.

The property manager persona kept me honest throughout. Every time I was tempted to optimize for a simpler-looking screen, I'd come back to Michael: someone juggling three properties, fifteen-plus tenants each, checking his phone between meetings. That framing didn't just define the architecture - it held the architecture in place when the design impulse said to simplify.

If I were to continue this project, I'd want to put the onboarding flow in front of a real property manager before touching anything else. Ten steps is a hypothesis. The right number is whatever number doesn't cause abandonment before the first lot goes live.