← BACK
Smart Client
2026
AI-native CRM
Italy
The company asked us to explore what AI could actually do for our products. At the same time, another team was evaluating CRM software to buy. I took both questions literally: instead of writing an assessment of the tools on the market, I designed and shipped a CRM of our own.
Nothing we could buy matched how business-management software actually behaves in our domain — the client lifecycle, the role model, the validation rules we already knew worked. Smart Client is what came out: a CRM for small Italian businesses, built on those patterns, with AI wired into the domain rather than bolted onto the side. In 17 focused work days it went from first sketch to a working product in front of real users.
My role: designer and developer — research, UX, UI, frontend, backend, AI integration, and the demo site used for the value-proposition sessions. Deployment was done together with one of the company’s senior developers, who brought the back end in line with internal engineering standards.

The Challenge

Small Italian businesses run sales out of a spreadsheet, an inbox, and memory. The CRMs available to them fail from two directions: enterprise platforms scaled down badly (overbuilt, English-first, priced per seat), or contact lists scaled up badly (fast to start, brittle by month three). Neither is designed for a company of three to fifteen people.
The brief I set myself had two parts. Design a CRM that fits how these companies already work — and prove it rather than pitch it. AI-assisted development changes the economics of a design exploration: what used to be a deck and a clickable prototype could now be a running product with authentication, a database, and a real API. That was the actual bet, and the reason to make the work public inside the company.
The constraint that shaped every decision: one person, weeks not months, and no shortcut that would make the result unusable in a real user test.

Research & Discovery

Thirteen years on business-management products meant I wasn't starting from zero. The research was about testing what transferred and what didn't:
  • ● Pattern audit of our own products
    Extracted the interaction and validation patterns that already work for Italian SMBs in our management software, and treated them as the starting design system.
  • ● Competitor analysis
    Benchmarked HubSpot Free, Pipedrive and Zoho against Italian tools like TeamSystem and Danea, to separate what SMBs adopt from what they abandon after the trial.
  • ● Domain modelling
    Mapped the Italian sales cycle onto two explicit models: a client state machine (LEAD → CONTACT → CLIENT) and a separate opportunity pipeline (Qualification → Proposal → Negotiation → Won), so that who someone is and which deal is open stay two different questions.
  • ● Technical spikes first
    Prototyped the risky pieces before designing around them — single sign-on, the drag-and-drop pipeline, and letting the assistant act on real records with a confirmation step. Knowing what was cheap and what was expensive shaped the scope honestly.

Insights

  • Goal The pipeline is the front door

    Nobody wants "a CRM". They want a place that shows what's worth doing this week. The Kanban board had to be the landing view, not a tab inside a dashboard.

  • Puzzle State changes are decisions, not data entry

    Moving a client from lead to customer is a business moment. Enforcing valid transitions server-side protects the user's mental model far better than a tooltip explaining the rule.

  • ⚠ AI must propose, never act

    Drafting, summarising and suggesting were welcome. Sending an email or changing a record without confirmation was a dealbreaker every time it came up. Human-in-the-loop wasn't a safety feature — it was the adoption condition.

  • ⊞ "What should I do today?" beats "here's your data"

    The most valuable output isn't a dashboard. It's a short, ranked list of things worth doing now, each with the reason next to it — which is a scoring rule, not a generated answer.

The Idea & Exploration

I built the MVP before asking for anything. The first version had the client lifecycle, the pipeline, and quotes — no AI at all. I showed it to the managers running the CRM evaluation as a working build they could click through, and the conversation moved immediately from "should we buy something" to "keep going, and put the AI inside it". A prototype that runs makes a better argument than a slide that describes one.
With the go-ahead, the next problem was no longer design: it was getting the thing off my laptop. I worked with one of the company’s senior developers, who brought the back end in line with our internal engineering standards so it could be deployed on a company development server. That collaboration is what turned a build only I could open into a product colleagues could reach with a link, and it is the reason the user tests later ran against a real deployed environment instead of a prototype.
Making AI native meant binding it to the domain instead of dropping a chat box on top. Eleven tools give the assistant real access to clients, opportunities, activities and quotes — read, create and update — and every write stops at an explicit confirmation step before it runs. The daily priority list deliberately sits outside the model: it's a deterministic scoring engine, because a ranking a user has to trust every morning should be a rule they can question, not a generation they can't.
Design and implementation ran as a single loop rather than a handoff. Working in git with an AI pair meant a sketch could be a running screen the same afternoon, so the exploration happened in the real medium — with real data, real latency, and real edge cases — instead of in a prototype that hides all three.
PROBLEMS RESEARCH IDEATION TESTING SOLUTION PROBLEMS RESEARCH IDEATION TESTING SOLUTION

Testing & Iteration

We ran sessions with five real users from the target market, testing two things at once. First the value proposition, using a product site I designed and built for the purpose: could someone understand what this is, who it's for, and why it's different, without anyone explaining it? Then the product itself — on a working staging build, not a Figma prototype.
Each session covered the same path: create a client, move it through the pipeline, generate a quote, and complete one AI-assisted task. Fixes shipped between sessions — the loop from a participant's comment to a deployed change was hours, not sprints. That is the part of this project that changed how I work: the cost of acting on feedback dropped far enough that there was no reason to defer it.

Testing Insights

  • The message landed before the product did

    Participants could explain what the product was and who it was for from the site alone, without prompting — the positioning held up before anyone touched the app.

  • The pipeline needed no instructions

    Every participant moved their first card unprompted. The spreadsheet-adjacent mental model transferred exactly as the pattern audit predicted.

  • Server-side validation read as guardrails, not friction

    When an invalid state transition was blocked, users read the message and adjusted. Nobody tried to force it, and nobody described it as the software getting in the way.

  • The confirmation step is what made the AI usable

    Seeing the proposed action before it ran was named explicitly as the reason participants would let the assistant near their client data. Auto-execution would have cost the trust the rest of the product earned.

Results & Impact

An exploration that was supposed to end in a recommendation ended in a product people asked to buy.
17
Focused work days from first sketch to a product in front of real users — design, frontend, backend and AI integration
4 / 5
Users strongly interested at the end of the test — two of them asked to buy it, unprompted
11
AI tools bound natively to the domain — read, create and update — with every write behind a human confirmation step
  • ● 12 product domains shipped
    Clients, opportunities, pipeline, activities, contacts, communications, documents, quotes, settings, statistics, AI and messaging.
  • ● Two artefacts, one window
    The CRM and the product site used to test the value proposition were designed and shipped in the same 17 days.
  • ● Production-shaped, not demo-shaped
    Bilingual UI with runtime switching, role-based visibility across three roles, and a documented contract between front end and back end rather than a hard-wired demo.
The point of this project isn't the software. It's that the distance between a design decision and evidence about that decision collapsed. Working in git with AI as a development partner, I could put a real product in front of real users in the time a discovery phase usually takes — and answer the acquisition question with a user test instead of an opinion. That is what I take from thirteen years of designing complex products into the way I work now: the judgement about what to build stays the same, but the cost of finding out whether I was right has changed.