Built for people who aren't techies

Who we picture

When we design a feature, we don't picture a developer with three monitors. We picture a 64-year-old shop owner, a busy parent, a retired teacher writing down family stories. People who are sharp and capable, but who never signed up to learn what an "API key" or a "token limit" is.

If the product only makes sense to people who already think like engineers, we've failed the people we built it for.

What that means in practice

• Plain words, always. No jargon in the interface. You don't "configure an integration" — you say what you want done. The assistant asks for what it needs in normal language.
• One thing to talk to. You're never asked to choose which model, which agent, or which mode. You talk to the PA; it handles the choosing. (See One assistant, a whole team behind it.)
• No dead ends. When something can't be done, you get a plain explanation and a next step — not an error code.
• Forgiving by default. Nothing important happens without a clear, readable summary you can approve first.

A small example

A technical tool might tell you: "Rate limit exceeded (429). Retry after 60s."

GabForge says: "You've sent quite a few requests in the last minute — give me about a minute to catch up, and we'll carry on."

Same underlying fact. One of them makes you feel stupid; the other treats you like a person. We choose the second one every time.

Why this is a feature, not a coat of paint

It's tempting to think "friendly wording" is something you sprinkle on at the end. It isn't. Building for non-technical people forces better decisions everywhere: simpler flows, safer defaults, fewer settings, clearer summaries. The plain-language goal makes the whole product better — including for the techies, who also quietly prefer software that doesn't make them work.