What we do, and how.
A new product and a platform an organization already runs on are different starting points for the same kind of work: software people depend on, built to keep working and to keep evolving.
One kind of work, three connected parts.
They stay connected throughout, rather than being treated as separate handoffs. There is no fixed entry point and no fixed end point.
Product definition
tells design what to make and for whom, and engineering what must exist and what must not change.
Design
is done knowing how the software will be built, and returns what the interface reveals.
Engineering
is done knowing who will use the software, and returns feasibility, constraints and the cost of change.
The software in use
sends new needs and platform constraints back. That is what built to keep evolving means.
The three parts
Product definition
- Covers
- What the software has to do, for whom, under which constraints: the problem, the people, their workflows.
- Leads when
- The need is clear and what should be built is not defined yet.
- Ends in
- A scope for a first version, requirements, an architecture direction, and the build that follows.
Design
- Covers
- UX and UI, interaction, design systems, prototypes where a decision needs one. Several roles means several views of the same data.
- Leads when
- A new product has to be defined, designed and built as one piece of work.
- On a platform in use
- Designs inside the platform's own conventions, not against them.
Engineering
- Covers
- Front-end and backend, APIs and integrations, architecture, releases and compatibility.
- Leads when
- The platform has to do something new, exchange data with other systems, or keep working through its next version.
- Built with
- React and Next.js, Node.js and PHP, and inside Moodle.
How work runs
No fixed sequence: four things that come up in almost every piece of work.
How we start
From the problem, not from a specification. The people who will design and build the software do this first, and it ends in decided things: scope, requirements, architecture direction.
Design and engineering together
Decisions taken at the same table, by people who hold both. It ends in software that could be built as designed, and used as built.
Handover and evolution
A repository from the start, documented as it is built, and a handover step when the engagement includes one. It ends in software someone other than us can run and change.
Working on a platform in use
A platform people log in to every day cannot be stopped for the work, and it will have a next version. This is how our own product is run: mooDesk is verified on Moodle 4.5, 5.0, 5.1 and 5.2, with a test matrix across PHP 8.2–8.4 on MariaDB and PostgreSQL.
One product, several roles, one platform underneath.
Each role has interfaces designed for what it has to do. Underneath, mooDesk uses Moodle's own permissions, privacy API and global search.
We designed and built this website ourselves: its design system and the code behind it.
What this page does not show
- No client definition phase is publicly shown.
- Publicly shown on Moodle; no attributable example on another platform yet.
- No attributable client platform or upgrade project is publicly shown.
- We have also worked on other kinds of platforms (portals, case management, member systems); that work is not publicly shown.
Start a conversation
Tell us about the product or the platform: what it has to do, what it runs on, what is in the way.
Start a conversation