About
About LoomReach
A London-registered software company. Whoever plans your project also builds it, and your contract names your main contact and a second one.
Who we are
We build websites, customer portals, CRM and internal tools, and connect them to your accounting and other systems. After launch, we look after them if you want us to.
So far we have built for manufacturing, wholesale distribution and healthcare businesses, and we run a subscription product of our own.
We work remotely on UK hours and come on site when a project needs it. Every document, report and review is in English.
How we work with you
-
Hours
09:00–18:00 UK time, Monday to Friday, by email and phone.
-
Two named contacts
Your contract names your main contact and a second one. Nobody else joins without telling you in writing first.
-
Cover when someone is away
Planned time off is announced at least five working days ahead, with the person covering named.
-
A written report every Friday
What was done, what is blocked, what comes next, and any date that moved.
-
Clear contracts
Under English law and invoiced in pounds sterling, with the full price before you sign.
What we build with
Tools with public documentation that many developers know, so another team can take a system over. We list only what runs in systems we have built.
- Languages
- Back end
- Express · FastAPI · SQLAlchemy with Alembic migrations · custom WordPress themes and plugins
- Front end
- React with Vite and Tailwind · Astro · plain-JavaScript single-page apps · server-rendered PHP and Jinja2 templates · web apps that install on a phone (PWA) · print-ready HTML and CSS for PDF catalogues · right-to-left layouts for Arabic and Hebrew
- Data
- PostgreSQL · SQLite · read-only links into Microsoft SQL Server · Parquet with DuckDB for analysis
- Running it
- Linux servers with PM2, systemd and nginx · Docker on Google Cloud Run · Firebase Hosting · managed PHP hosting
- AI
- the Anthropic Claude API with structured output and prompt caching · OpenAI speech-to-text, embeddings and image generation · ElevenLabs voice
- Systems we have connected to
- an ERP system · Xero · Stripe · banking APIs · a national delivery service · public-procurement and company-registry APIs · Telegram · WhatsApp · Viber · a telephony service · Gmail and Google Workspace · Google Ads and GA4 with Consent Mode v2 · Algolia · intervals.icu · Cloudflare Turnstile
- Testing
- Jest with supertest · pytest · Vitest · Playwright · shell acceptance suites
How we keep it working
What you would find in the code and release scripts of systems we have built. Where a practice is in only some of them, we say so.
Migrations kept with the code
On three of our systems, database changes ship as migrations kept with the code, written so that running one twice does no harm.
Automated tests
On our largest system, the server has 500+ automated test files, written with Jest and supertest.
End-to-end acceptance tests
On our ordering portal, acceptance tests start a throwaway database, the real server and a stand-in for the outside API it depends on. They then check the behaviour end to end. We run them by hand before a release; there is no hosted CI pipeline.
A check after each release
On three of our systems, a quick check calls the live system after a release. On one of them, a failed check switches back to the previous version automatically.
Committed code only
On three of our systems, production runs committed code only. On one, the release script refuses uncommitted changes; on another, a drift check compares the live server with the code.
Integration alerts
On our largest system, integrations are watched: if a bank feed, an ERP sync or a mail sync stops updating, an alert goes out the next morning.
Safe retries
On two of our systems, syncs with outside systems can be retried safely. On our ordering portal, a resent order is recognised, not duplicated, and a scheduled full resync catches deletions that a partial update can't see.
Incident notes in the code
On four of our systems, when something breaks, the cause and the fix are written next to the code that changed, with the date.
We don't hold a security certificate or promise an uptime figure.
Rules we hold ourselves to
-
Write it down first.
Nothing is built that wasn't agreed in writing, and nothing is invoiced that wasn't agreed first.
-
Leave nothing only we can run.
Code, accounts and running instructions sit in your company's name, so another developer can take over at any time.
-
Say the awkward thing early.
A date that is slipping, a request outside the plan, a tool that is wrong for you, a project we shouldn't take. You hear it straight away.
-
Use ordinary, well-known tools.
We pick tools that many developers know, so your system never depends on us alone.
-
Show only what we can back up.
Our work is described from its code, without client names. We don't publish reviews, logos or figures we can't support.
Check us before you write
Our company filings are public at Companies House. Our supplier pack has our NDA, data-processing agreement, contract template and blank project documents.
Tell us what you need
A few sentences is enough. Our first reply says whether we are the right fit.
Written reply within one working day. No sales calls.