Software studio · Milton, Cambridge

Built to tolerance

Sedge designs, builds and releases mobile apps and websites. Every state is specified, every release is checked and every handover is documented.

Request a scoping call Try the state inventory

Blueprint-style drawing of sedge stems beside an outline of a mobile phone, with dimension lines — Generated illustration · drawing style, not a real product

What we do, plainly

We remove ambiguity before it gets expensive

Most software faults come from small gaps rather than hard technology: a disabled button nobody designed, an error message nobody wrote, a time-zone assumption that holds until the clocks change. We find those gaps on paper, while fixing them takes minutes rather than a release.

So our documents read like engineering drawings. Each screen lists its states. Each feature has acceptance criteria. Each release has a written test record. That paperwork is the shortest route to a product that behaves the way everyone expected.

Service schedule

What each service covers, and what you receive

Service	What we do	You receive
Mobile applications	iOS and Android apps, usually from one shared codebase, tested on real devices with large text, screen readers and poor signal.	Source in your repository, TestFlight and Play testing builds, a device test record
Web development	Websites, portals and web apps with page-weight and loading targets agreed at the start and checked before launch.	Accessible front end, editing guide, hosting note, redirect map
Interface design	Flows, wireframes and visual design, with every state listed: default, loading, empty, error, offline and permission denied.	State inventory, prototype, component library with notes
Release & publishing	Developer accounts in your name, signing, listings, privacy declarations, reviewer replies and a gradual rollout.	Release checklist, listing copy, rollback plan
Aftercare & support	Dependency updates, preparation for each year’s operating-system releases, error monitoring and fault handling during working hours.	Written scope, monthly maintenance log

Interactive · state inventory

One screen, six states

A design usually shows the happy path. Users see the rest. Choose a screen and a state to see the kind of detail we write down before building. Each state needs its own wording, layout and next step.

Screen

Interactive · release planner

Work backwards from your launch date

Enter the date you want people to have the product. The planner counts back through the checkpoints we would usually schedule. Store review times vary and can’t be guaranteed, so we build in a buffer. Nothing is sent or stored.

A drafting table with a printed app layout, a steel ruler and a pencil — Generated illustrative image · not Sedge premises

Working approach

How a fortnight runs

Start: We agree the increment together: which flows, which states and which acceptance criteria. Anything unclear is written down as a question rather than left as an assumption.
Middle: A short check-in on what is harder than expected. If scope has to move, we tell you then, in writing, and not at the end.
End: A working build, a change log and a test record listing what was checked, what failed and how it was fixed.

Fewer meetings and clearer documents. Those records become your handover, so the next person to work on the product starts from facts.

How the practice works

Where to start

Where is your product right now?

Start with a scoping sprint: users, flows and a specification you can price against. See interface design.

From our notes

References we use on every project

WCAG 2.2
The accessibility standard behind our design reviews. We aim for level AA and record any gaps honestly.
Android design guidance
How Android users expect navigation, back behaviour and system settings to work.
Apple Human Interface Guidelines
The iPhone equivalent. Worth reading before you approve a design that ignores them.
OWASP Top Ten
A shared vocabulary for common web security risks. We use it as a reference, not as a certificate.

All notes and references

Aftercare, stated precisely

Included when agreed

Library and security updates
Preparation for new iOS and Android versions
Error monitoring reviewed on working days
Fault investigation with written findings

Not assumed

Out-of-hours response, unless agreed separately
New features outside the agreed scope
Fixes to third-party services we don’t control

Reporting a fault

Use the aftercare page form or email qa@sedge.trade. Include the steps to reproduce it, what you expected and what actually happened. We work Monday to Friday, 09:00–18:00 UK time.

Questions, answered to specification

Will you give a fixed launch date at the first call?: No. A date before the specification exists is a guess. After the scoping sprint, we give a costed plan with ranges and the assumptions behind them.
Who owns the code, designs and accounts?: You do. We work in your repositories and developer accounts as invited team members.
Can you test an app another team built?: Yes. A pre-release audit covers device testing, accessibility, privacy declarations and store readiness, with a written report.
What does the scoping sprint produce?: User flows, a state inventory for each screen, acceptance criteria for each feature, a list of risks and open questions, and a costed plan. It is yours to keep, even if you build elsewhere.
How do you handle accessibility?: It is written into the specification, not added at the end. We test with keyboard, screen readers, zoom and large text, aim for WCAG 2.2 AA, and list any known gaps in the release record.
Do you publish client work?: Not without consent, which is why this site has no logos or testimonials. We can discuss relevant work privately where clients have agreed.
Where are you based?: 270 The Rowans, Milton, Cambridge, England, CB24 6ZL. Meetings are by appointment, in person or by video.