How we build
From a real problem to software you can check.
Every product goes through the same six steps. The order is the point: we understand the problem and the person before choosing any technology.
- 01
Start from a real problem
Something people already struggle with, not a technology looking for a use.
- 02
Understand the person
What they intend, what they know, and what they must stay responsible for.
- 03
Choose the right technology
The simplest thing that does the mechanical work well. Sometimes that’s AI. Often it isn’t.
- 04
Build the simplest useful system
Fewer moving parts means fewer ways to fail and less to trust.
- 05
Make its behaviour visible
Document what it connects to, what it stores and what it cannot do.
- 06
Keep improving
Publish the limitations, then work through them in the open.
And back to 01, with what we learned.
01/ 06
Start from a real problem
We begin with a task that is slow, expensive or risky today. Editing a PDF should not require an account, a subscription or uploading a contract to someone else’s server.
The question
Who has this problem, and what do they do about it now?
02/ 06
Understand the person
The human half of the dyad is the part that decides. We work out which judgments belong to the person and design the product so those stay with them.
The question
Which decisions must stay with the person?
03/ 06
Choose the right technology
The machine half should take the repetitive, exact and computational work. We choose tools by how well they do that job and by what they cost the user in privacy and control.
The question
What can the machine do better, and at what cost to the user?
04/ 06
Build the simplest useful system
A folder of static files with no backend is easier to secure, host and audit than a platform. We add infrastructure only when a feature truly needs it.
The question
What can we leave out?
05/ 06
Make its behaviour visible
Before release, each product gets a transparency page that answers the same questions in plain language, with steps you can follow to check the answers yourself.
The question
Could a user check this without taking our word for it?
06/ 06
Keep improving
Known limitations are listed next to features, and changes to promises are recorded with a date before they take effect. Then the loop starts again.
The question
What did we learn, and what do we fix next?
Where AI fits
The right tool, not the fashionable one.
Machine learning is one of the machine’s capabilities, and a powerful one. We use it when it does the job better and costs the user nothing they shouldn’t have to give up.
Example: PDF Editor
- Included
- OCR that turns scanned pages into searchable text, running on your device.
- Left out, on purpose
- A cloud “chat with your PDF” assistant. It would mean sending your document to a server, which breaks the product’s central promise.
Standards
Engineering is the product.
The rules every DyadForge product is held to before it ships.
- Architecture
- Process on the device when the task allows it. Add a server only when a feature cannot work without one.
- Security
- A strict Content-Security-Policy that the browser enforces, so the product cannot contact destinations it doesn’t declare.
- Privacy
- No analytics, no advertising identifiers, no accounts unless a feature needs one.
- Accessibility
- Keyboard access, visible focus, sufficient contrast and reduced-motion support are requirements, not follow-ups.
- Performance
- Static files where possible. Heavy components, such as an OCR engine, load only when they are used.
- Portability
- Standard output formats that open in any other tool. Your work should never be locked into ours.
This website follows the same rules.
- Static HTML, generated at build time
- No cookies or analytics
- No third-party requests. Fonts are served from dyadforge.com
- Your theme choice is stored only in your browser