Expertise

Software & SaaS

My software work starts with the operating problem and the business rules the product has to support.

How I approach it

What this means in my work.

I have worked as a functional architect, product owner, requirements author, and earlier in my career as a hands-on developer. The common thread is translating operations into software behavior: users, workflows, data, permissions, controls, exceptions, integrations, and acceptance criteria.

That background makes me skeptical of software that automates a poorly understood process. I prefer to establish the operating model first, then use technology to make it faster, clearer, more controlled, or easier to scale.

In practice

Software is an operating model expressed in rules and behavior.

The examples include commercial software, internal manufacturing systems, and inventory platforms.

7 projects represented here

Across these examples

The recurring pattern.

Across the software work, the constant is functional architecture: understand the users and operating rules, make requirements explicit, design for exceptions and controls, and test whether the product actually supports the intended work.

Contact

Have a reason to discuss this kind of work?

Contact Dean