Paritrue Ltd / Shifnal, Shropshire
Software, set true.
We build mobile applications and websites the way an engineer makes a part: drawn first, dimensioned, made to a stated tolerance and checked before it leaves the bench.
- Issued by
- Paritrue Ltd
- Applies to
- iOS and Android apps, websites, web applications
- Includes
- Design, build, release, support
- Office hours
- Mon–Fri, 09:00–18:00 UK time
Every engagement starts with a short written specification you can read, question and keep, whether or not you then hire us to build it.
Our tolerancesScope of supply
What each discipline delivers, and how it is checked
A service description is only useful if you can verify it. This table lists what you receive from each part of the practice and the check that has to pass before we call it finished.
| Discipline | You receive | Acceptance check |
|---|---|---|
| Mobile applicationsFull specification |
| Key journeys pass on the agreed device list, including the largest text size and a screen reader. |
| Web developmentFull specification |
| Pages meet the weight budget, work at 320 pixels wide and at 200% zoom, and forms keep input after an error. |
| Interface designFull specification |
| Each tested task is completed by participants without help, or the design is revised and retested. |
| Release & publishingFull specification |
| Declarations match the code and libraries; a backup is restored once before switch-over. |
| SupportFull specification |
| Every fix is reproduced first, then verified on the device or browser where it was reported. |
Before a line of code
The specification, explained
Most software disappointments trace back to something nobody wrote down: a device nobody tested, a field nobody validated, a deadline nobody compared with the work. Our specification exists to surface those things while they are still cheap to change.
It is short, usually a handful of pages, in plain English. You approve it before development starts. When something changes, and something always does, we amend it and show you the effect on time and cost.
- PurposeWho the product serves and the outcome it should produce.
- InclusionsScreens, features and integrations that will be built.
- ExclusionsWhat we have deliberately left out, so nobody assumes it.
- TolerancesPerformance, accessibility and supported devices, stated as limits.
- VerificationHow each requirement will be tested and by whom.
- HandoverThe accounts, code and documents you will hold at the end.
Instrument
Weigh your project
Every project balances what you want built, and how polished it must be, against the time available. Move the sliders to see whether a plan is within tolerance. When it tips, something has to give: reduce scope, accept a plainer finish, or allow more time.
It is a thinking aid, not a quotation. Nothing is sent to us, and settings are remembered on this device only if you accept optional storage.
Instrument
Build a test matrix
“Tested on all devices” is not a measurement. Tell us a little about your product and audience, and this tool drafts the kind of device and browser list we would put in a specification. It runs entirely in your browser.
Working sequence
From survey to steady running
The stages are fixed; the time spent in each depends on your project. Each stage ends with something you can inspect.
Survey
A call and a short questionnaire about the problem, the people and the constraints.
Specify
The written specification and, where useful, a clickable prototype.
Build
Short cycles, each ending with a build you can install or open.
Verify
Testing against the agreed matrix and accessibility checks.
Release
Store submission or go-live, with a rollback plan ready.
Maintain
Updates and fixes on a schedule, or a complete handover.
After release
Support that keeps the readings true
Software drifts out of tolerance without anyone touching it. Apple and Google release new operating systems every year, browsers change behaviour, and libraries publish security fixes. Our support arrangements schedule that work instead of waiting for something to break.
You can choose routine maintenance, maintenance plus a regular allowance for improvements, or ad hoc work quoted when needed. Whichever you choose, every change is logged so you always know what was done and why.
Support and fault reportingA useful fault report contains
- What you expected to happen
- What happened instead
- The steps that lead to it
- Device, operating system or browser, and app version
- When it started, if you know
Please never send passwords or your customers' personal data.
From the reference shelf
Sources we measure against
Content should be presentable without loss of information when zoomed, without scrolling in two directions.
Before submitting, test your app thoroughly on devices and make sure metadata and links are complete.
Declare all user data your app and its third-party libraries collect or share.
Keep software and devices up to date; most attacks exploit known, fixed weaknesses.
Questions
Asked before most projects
Will you give us a fixed price?
For a well-specified piece of work, yes. Where too much is unknown, we suggest a short paid specification phase first, then price the build against the document you approved.
Who owns the code and accounts?
You do, from the first day. Repositories, developer accounts, hosting and domains are created in your organisation’s name and we are invited as team members.
Native or cross-platform?
We decide against written criteria: hardware access, performance needs, team skills and maintenance budget. The reasoning goes into the specification so you can revisit it.
Can you take over an existing product?
Yes. We start with a review of the code, dependencies, accounts and release process, then report what is sound, what is at risk and what we would fix first.
Do you meet clients in person?
Mostly we work remotely. Our Shifnal address is a correspondence address, so any meeting is arranged in advance.
How quickly do you reply?
We read enquiries Monday to Friday, 09:00–18:00 UK time, and reply in working hours. Clients on a support arrangement use the response terms in their agreement.