The person using it
Customers, members or staff who meet your interface for the first time, often on a phone, often in a hurry. We test wording and layout with people who have never seen the product, and fix what they misread.
Illustrative generated image — not our premisesSoftware studio · Oxford Road, Manchester
Software you can read.
Codexana designs and builds web and mobile products with one non-negotiable rule: the next person to open the code, the interface or the documentation should understand it on first reading.
Directory of services
| Symbol | Service | Best for | Go to |
|---|---|---|---|
| Web development | Customer portals, booking flows, internal tools and content sites | Web | |
| Mobile development | iOS and Android apps for field teams, members and customers | Mobile | |
| UI/UX design | Clarifying journeys, information architecture and interface systems | Design | |
| Publishing | Store submissions, domains, release notes and go-live checks | Publishing | |
| Support | Maintenance, fixes, dependency updates and readable change logs | Support |
How a project travels
Select a stop on the line to read what happens there and what you receive.
Orientation
We read what exists — code, documents, spreadsheets, user feedback — and write a one-page orientation: who the product serves, what it must do, what is unclear.
You receive: orientation page, list of open questions.
Plan
The work is divided into small, named increments, each with a definition of done written in plain English so anyone in your team can check it.
You receive: increment plan, cost range per increment.
Build
Code is written to a shared style, with descriptive names and tests for the behaviour that matters. Every increment ends with a working preview.
You receive: preview link or test build, short change summary.
Review
A second developer reviews every change for correctness and readability. You review behaviour against the definition of done.
You receive: review notes, accepted increments.
Release
A written release checklist covers accessibility, security, content and rollback. Releases happen during working hours.
You receive: release notes, completed checklist.
Handover
Repositories, accounts and documentation move into your ownership with a walkthrough for whoever maintains the product next.
You receive: repository, run-book, architecture notes.
Why legibility matters
Most software spends far longer being read and changed than being written. Code that only its author understands becomes expensive the day that author moves on. Interfaces that need a training session lose customers who never ask for one.
Codexana treats legibility as a deliverable: naming conventions agreed at the start, documentation written alongside the code, and interfaces tested for clarity with people who have never seen them.
About CodexanaPlain-English checker
Paste a paragraph from your app, website or help page. The checker flags long sentences, long words and common jargon so you can see where readers may stall. It runs only in your browser; nothing is sent or saved.
- Sentences
- –
- Average words per sentence
- –
- Sentences over 25 words
- –
- Jargon found
- –
- Press “Check this text” to see suggestions.
Who reads what we make
Every product we build has at least three audiences. We design for all of them from the first week, not just the first one.
The developer who inherits it
Someone will maintain the code after us, possibly your own hire. Agreed naming, small modules, tests that describe behaviour and a written architecture note make their first week productive rather than baffling.
The person who pays for it
You need to understand progress, cost and risk without reading code. Weekly updates use three headings: done, next and blocked. Estimates list their assumptions so you can challenge them.
A handover you can actually read
When a Codexana project changes hands, the repository opens with a short read-me written for a stranger. This is the skeleton we start from. You are welcome to use it on any project, with us or without us.
- Fits on one screen; detail lives in linked documents.
- Every command is copied from a working terminal, not from memory.
- Named owners for accounts, so nobody is locked out later.
# Product name One sentence: what it does and for whom. ## Run it locally 1. Requirements (with versions) 2. Install command 3. Start command and the address it opens ## Where things live src/ application code, one folder per feature tests/ behaviour tests, named after user actions docs/ architecture note, decisions log ## Release Checklist: docs/release.md · Rollback: docs/rollback.md ## Accounts and owners Hosting, stores, domain, email: owner and contact
After launch: support you can follow
FixesFaults are reproduced, fixed with a test that proves the fix, and explained in the change log in ordinary language.
UpdatesOperating-system, browser and dependency updates are applied on a schedule, so the product never drifts years behind.
ChecksCertificates, backups, error logs and security advisories are reviewed periodically and summarised for you.
HoursRequests are read Monday to Friday, 09:00–18:00 UK time. Response arrangements are agreed in each support plan.
Information desk
Can you take over code another team wrote?
Yes. We start with an orientation: reading the code, running it, and writing down what is unclear or risky. You receive that note before committing to further work.
Do you only build new products?
No. A good share of legibility work is improving something that exists — renaming, documenting, splitting large files and adding tests around fragile behaviour.
Which technologies do you use?
Well-established, widely understood frameworks for web and cross-platform mobile. We choose what your future maintainers are most likely to know, and explain the choice in writing.
Will our team understand the code?
That is the point. Naming conventions are agreed with you, and handover includes a walkthrough with whoever maintains the product next.
How are estimates given?
As ranges per increment, with assumptions listed. If an assumption proves wrong, we tell you before the cost changes.
Where are you based?
Our registered office is on Oxford Road in Manchester. We work with clients across the UK, mainly through calls and shared preview builds.