How do you turn ten years of expertise into software?

The software itself wasn’t especially difficult to build. The interesting work was figuring out what it needed to know.

We were working with a cybersecurity consultancy with more than ten years of experience. They worked with large companies and wanted to make their expertise useful to smaller businesses too.

The idea was a virtual CISO SaaS for small and medium-sized businesses. A customer would sign up, answer questions about their company, and get a cybersecurity strategy with a plan they could track and action items they could start working on.

That sounds straightforward when you describe it as a form and a dashboard. Sitting down with the consultants made the question more interesting: how do you turn years of experience into a process that can make useful decisions from someone’s answers?

Getting something on a screen is cheap now. A form is easy enough to put together. The decisions behind the questions deserve more attention.

We rolled up our sleeves together and started digging into how the consultancy worked with its existing clients. We read their documents and spreadsheets, worked through customer interviews, and talked through how they assessed a company and arrived at a plan.

This took time. We needed to capture the reasoning behind their work: what they needed to know about a company, how they interpreted its answers, and how that shaped their advice. That meant getting into the details of an approach they had spent years developing.

We brainstormed together as we went. We were looking for a structure that could carry those decisions into software and connect them to something useful for the customer. The questions, the answers, and the recommended actions had to make sense together.

Out of that work came the domain model. We identified the domains that defined how secure a company was. A domain is a broad area of security that you need to understand about a business.

Each domain contained subdomains, and each subdomain had action items associated with it. That gave us a way to connect the assessment to something a customer could actually work on. Access management, for example, is about who can get into the company’s systems and what they can do once they’re there. Subdomains break that into smaller parts you can examine: how accounts are created, how permissions are reviewed, and how access is removed when someone leaves.

Imagine a company has no consistent process for removing that access. You’ve found a specific gap inside a broader area of security. An action item could be to create an offboarding checklist and give someone responsibility for following it. That’s what makes the structure useful: you can trace an area of concern down to a concrete piece of work the business can own.

Once we had that structure, we could work through the questions against it. We needed to understand what each answer changed and how it connected to the next step in the assessment. Those relationships had to be explicit before we could rely on them in software.

That led us to build the form around a finite state machine. In ordinary language, the customer’s answers could change the path through the assessment. The form could send different companies through different sequences of questions, using the logic we had shaped with the consultants.

Take a company that already has a HIPAA compliance program for handling protected health information. The assessment could follow up on how it protects that information in practice: who can access it, what safeguards are already in place, and how those safeguards are reviewed. Saying you have a compliance program gives the form something to investigate. It doesn’t answer those questions for you.

Now imagine another company is working toward ISO/IEC 27001 certification. The assessment could explore the scope of its information security management system, how it assesses risk, and what processes it still needs to put in place. The starting point and the goal change what you need to ask next, and which actions belong in the plan. That’s the kind of difference the branching logic needs to carry.

A company could need both, too. The route has to account for what applies to the business, what is already in place, and what it wants to achieve. There’s a lot of thought hiding inside that kind of interaction. The person filling in the form sees the next question. Behind it is a decision about what information matters at that point and how it connects to the rest of the assessment.

The consultants knew their field and liked the approach. They helped us get the model into the right shape. We could work through what their experience meant for the product while also thinking about how someone would move through it. Both kinds of thinking needed to happen in the same conversation.

Once we had that shape, the implementation was manageable. Another part of the build needed more discussion: how much security work belonged in the first version.

We were building an MVP and wanted to get something ready to try quickly. The consultancy had strong security expectations. We spent a considerable amount of time working through their testing and adding extra layers of security.

I questioned how much of that work needed to happen in the MVP. I also understood where they were coming from. Security was their craft, and they wanted to look closely at the details of the platform.

The MVP was going to handle real company information from businesses partnered with the consultancy. That was part of the context for those discussions. We were building something people would use with their own information.

I still think scope is worth questioning at that stage. You want to try the product and learn from it. You also need to understand what each requirement is protecting. The useful discussion is specific: what does this add, what does it cost us now, and what would happen if it waited?

We worked through the testing and additional security work and still delivered the MVP in a timely manner. I wouldn’t describe the engineering as unusually difficult. There was simply more to the work than implementing the screens.

Building products of our own makes those conversations familiar. You spend time thinking about what to try first, which decisions will be expensive to change, and what someone needs in order to get value from the product. Those questions keep showing up, whatever the size of the company.

Looking back, the part that interests me most is the distance between the first description of the idea and the model we could build. A consultancy’s experience became domains, subdomains, actions, and paths through an assessment. Each of those relationships had to make sense to the people who understood the subject.

A customer answering a question wouldn’t see the conversations behind it. They would just see the next step. A lot of the craft went into deciding what that step should be.

From the kitchen, with curiosity.