Software your customers can figure out on their own.

What a first version should and shouldn’t do

Most software businesses don’t stall because the code was bad. They stall because they spent their budget building features nobody asked for, before finding out whether anyone would pay for the core one. For a small team, the first version is the most expensive guess you’ll make.

An MVP, or minimum viable product, is the smallest version a real customer will pay for or commit to. It isn’t a cheaper copy of the full product. It’s a complete answer to one narrow problem. We start by naming the first customer, the job they need done and what they do today instead, which is often a spreadsheet and a lot of email.

Then we cut everything that doesn’t serve that job and write down why, so you can see each trade-off and make the final call. Where it helps, we put a clickable prototype in front of those first customers before writing the code for the real product, so the scope is tested by the people who would pay for it rather than argued over in meetings.

Designing screens people use all day

Business software has a different job from a consumer app. Your users open it every morning, work through long lists of records and need to trust the numbers. A dashboard that looks impressive in a sales demo can be slow and confusing by the second month.

For Deep6 AI, a platform for recruiting patients into clinical trials, we ran 18 research sessions and nine design iterations on its table and map views. That’s what this kind of product needs: watching people do their actual work, then testing changes with them before anything gets built.

What we run into most often in existing products:

• Tables with no saved filters, bulk actions or sensible defaults
• Charts that show data without answering a question
• Empty screens on day one, with no hint of what to do next
• Settings and permissions added wherever there was room
• Five slightly different versions of the same button

A design system is what keeps a redesign from drifting back. It’s a shared library of components, colors, type and rules, kept in Figma and matched in code. Our design-systems work at bp came with more than 100 resource pages and over 25 workshops, because a system only holds when the people building with it understand it. Yours will be far smaller, with plain-language notes your developers can follow without a designer in the room.

Adding AI where it does a real job

Plenty of products now have a chat box in the corner that nobody uses. AI earns its place when it removes a step your customers already take: summarizing a long record, drafting a first reply, sorting incoming requests, or answering a question about their own data in plain language.

We start with that step, then design for the moments when the model is wrong. That means showing where an answer came from, letting people edit before anything is sent, keeping a person in charge of decisions that matter, and tracking what each request costs so your margins hold as usage grows. We build on major model providers through their APIs, the connections that let your product send requests to their models, and use settings that keep your customers’ data out of model training.

We test each AI feature on realistic examples before it reaches customers, and if a simple rule or a clearer screen would do the job better, we’ll say so. We use AI in our own work the same way: to speed up research, drafting and prototyping, with people reviewing everything that ships.

From marketing site to first session

A SaaS product is more than the app. Customers find you through a marketing site, make up their minds on a pricing page, sign up, and either reach a useful result in their first session or leave. We look at that whole path in the audit, because a strong product behind a confusing website still loses trials.

We can design your marketing site alongside the product so the two look and sound like one company, and plan launch campaigns when you’re ready for more traffic. If your customers also need a mobile app, it can share the same design system.

When the work is done, you own the code, the design files and every account. You can take it in-house, hire your own developers, or keep working with us in fixed-price phases. If you’re not sure where to start, a free audit gets you an honest read on your product or plan, and a concept to react to, before you commit any budget.