Who does the work
Accessibility and research
Tests every store and every product we make against WCAG 2.2 AA with a keyboard and a screen reader, verifies every fix, and runs the research and the handover.
Product and engineering
Designs and builds the products, the games and the fixes, from a store's theme to a whole app or game, and builds Goodspring Keel and Mayday League.
Goodspring Keel, Mayday League, this site and the tools Goodspring runs on were designed and built here.
How Goodspring operates
- Vendor-neutral by design.No third-party tools resold, no referral fees, and no tool recommended because it benefits us.
- The check comes first, and it is paid.Nothing is built before the problem is known.
- Nothing renews by default.Engagements end. Continued work happens only when a need justifies it, never because a contract does.
- A person makes every decision that matters.AI does much of the reading and the building. The decisions, and the reasons for them, stay with people.
- Neutral to dependency.Good work leaves you needing us less, not more.
What we refuse
- Selling an accessibility widget.We fix the store itself and add no overlay.
- Giving legal advice.We say what we found. What it means legally is a lawyer's call.
- Building anything for anyone.We take on products, games and problems we can scope, build and prove.
- Billing by the hour.Every piece of work has one price, agreed before it starts.
- Lock-in.Nothing you must keep paying us for in order to keep working.
- Reusing your data or your edge.We reuse general patterns only.
Find the need.
Every piece of work here starts with the person on the other side: who reads the page, what is in their way, and what it costs them. A store losing sales to an error nobody flagged. A maker who has to register one product in fifty states. A player who wants to feel speed. The need picks the kind of work, which is why one studio checks stores, builds apps, watches product registrations and makes a racing game.
Decisions are made quickly, one question at a time, with the options written out and one of them recommended. The plain version wins: fewer words, fewer steps, nothing on the page the reader has to work around.
Then the work gets used, not described. Each change goes live and is tried the way its own user would try it: a store with a keyboard and a screen reader, a page on a phone, the game at full speed. What breaks is fixed, and the fix is checked again.
The joy is how you know the need was met: a store that stops losing sales, a checkout that finally works with a screen reader, a race that feels as fast as it is.