Bespoke software and custom tools
When no plugin does it well, we build it.
We are programmers as well as SEOs, so a feature does not have to be whatever the plugin directory happens to offer. Bespoke software development in PHP and JavaScript, server rendered so it stays crawlable, and documented so you are never stuck with us.
Evidence
Four we built from scratch.
The first two are features living inside a client site. The second two are standalone applications with their own login, their own hosting and no WordPress underneath them at all. We cannot link to those two, because everything past the sign in screen is client data.
Geolocation search
A location finder that maintains itself
Built for a term with 33k searches a month. Geolocation API, Haversine distance sorting, radius filtering and reverse geocoded location labels.
The part we are most pleased with is the geocoding layer. It falls back from a static map, to a cached lookup on term meta, to a single external call, and caches the result. New locations work with no code change at all, so nobody has to call a developer to add one. Server rendered throughout, so it is fully crawlable.
Comparison tool
A three way comparison with real data behind it
Relationship data derived from existing post meta and made bidirectional, so the connections were real rather than hand maintained in a spreadsheet.
SVG connector graphics, location aware combined pricing, localStorage persistence so a comparison survives a refresh, and full undo and redo. DOM safe rendering throughout, which matters the moment you are injecting content a user selected.
Standalone app
A booking management system
Not a plugin bolted onto a website. A separate application with its own accounts, sign up, sign in and password recovery, running on its own hosting so a busy booking day cannot slow the public site down.
Built as an installable progressive web app with a service worker, so staff can add it to a phone home screen and it keeps working through a patchy connection. It loads in 236ms from four requests, which is the difference between a tool people use and a tool people avoid.
Standalone app
An SEO command centre for a client team
A private dashboard pulling a client's search data into one screen, with its own authentication, so the people running the site can see where things stand without waiting on a monthly report or learning to drive Search Console.
Charting and interface written in plain JavaScript rather than a framework, which is why the whole thing is eight requests and paints in 700ms. Deployed separately from the website it reports on, so neither can take the other down.
Why these two are not linked
Both sit behind a login and everything inside them is client data, so a link would only ever show you a sign in box. The numbers above were measured on the live sign in screens, which is the part we can show. If you want to see either one working, we can walk you through it on a call.
Scope
The sort of thing we get asked for.
Not an exhaustive list. If it runs on a web stack it is probably buildable, and if it is a bad idea we will say that too.
Calculators and quoting
Pricing, sizing, savings, eligibility. Straightforward to build, easy to get subtly wrong, and one of the most reliable ways to turn a browsing visitor into an enquiry.
Search and filtering
Faceted search with real logic underneath, built so the filtered views you want indexed are indexable and the endless combinations you do not are not. That distinction is where most filter systems wreck a crawl budget.
Comparison and configurators
Side by side comparison, product configurators, bundle builders. State that survives a refresh, sensible undo, and rendering that does not open an injection hole.
Location features
Near me search, store finders, service area checks, distance sorting. Including the geocoding layer underneath, which is the part that usually turns into a maintenance burden if it is built naively.
API integrations
Pulling a third party system into the site, or pushing your data out to one. We have built against Cloudflare's API for targeted cache purging and against geocoding APIs, among others.
Internal tooling
The unglamorous one, and often the highest return. Turning a manual spreadsheet process into an admin screen, bulk importers, or a script that does in seconds what someone currently does for two hours every Monday.
Customer portals and logins
An account area where customers see their own orders, documents, quotes or usage. Mostly a permissions problem rather than a design one, and the place where a generic plugin will eventually leak one customer's data to another.
Booking and availability
Slots, capacity, blackout dates, staff or room assignment, and the awkward parts nobody scopes: double booking under load, timezone handling, and what happens when someone cancels at the same moment as someone books.
Dashboards and reporting
Pulling numbers out of the systems you already run and putting them on one screen. Usually replaces a spreadsheet somebody rebuilds by hand every month, which makes the return easy to work out before we start.
Buy before you build
For several of these there is a good product on the market and buying it is the right answer. Booking and CRM in particular have mature tools that will beat a custom build on cost for most businesses. Building is worth it when your process genuinely does not fit the product, when the data has to live on your own infrastructure, or when the licence cost per seat has quietly overtaken the cost of owning it. We will tell you which situation you are in.
Stack
What we build it in.
The first group is what we work in every day and where our deepest work lives. The second is covered across the team. We would rather show you the difference than pretend it does not exist.
Core, daily
Across the team
Infrastructure
The honest bit
Nobody knows every language, and any agency that tells you it does is describing a sales position rather than a team. If a project genuinely needs something outside what we work in, we will say so rather than learning it on your budget. That has cost us work before and it is still the right answer.
How we build
Four rules that survive us leaving.
Server rendered by default
The content exists before the JavaScript runs. A tool that only assembles itself in the browser is invisible to crawlers, and if the tool is meant to earn traffic that defeats the point of building it.
No framework bloat
Vanilla JavaScript and PHP unless there is a real reason otherwise. Shipping a framework so a calculator can add two numbers is a cost your visitors pay on every page load.
Cache safe
Built knowing what happens when it sits behind a CDN, an object cache and an application cache at once. We have traced a cache failure to four separate root causes on one site, so this is designed in rather than discovered later.
Documented for handover
Architecture, deployed code, gotchas and a changelog. Nothing lives only in our heads, so you can take the work to another developer whenever you want to. That is the point.
Cost
What it costs.
Development is £90 to £100 an hour, quoted as a fixed scope once we know what the tool has to do.
Small tool
Scoped
A calculator or a filter with clear inputs and outputs. Days rather than weeks. If a plugin would genuinely do it, we will point you at the plugin instead.
Bespoke feature
Scoped
Something that sits on your real data, with logic that has to be right. Comparison tools, location search, configurators. The common case.
Tool as a link asset
Scoped
Built to earn coverage as well as convert, then pitched through digital PR. Costs more than an article and lasts considerably longer.
Fixed scope agreed in writing before work starts. Time logged as it is spent, including anything scrapped. Full breakdown on the rates page.
How we are set up
A team that can build it, one person you talk to.
There is a full team here. That is what lets us run a technical programme, a build and a link campaign at the same time without any of them waiting on the others, and it is why we can take on work that is genuinely too big for one person.
What it does not mean is an account manager. For the work itself you deal with me directly, and that does not change once you have signed. You will not be sold by one person and then handed to someone you have never spoken to.
Alin Boatca alinboatca@googlemail.com
- Capacity of a team Several workstreams running at once, so a build does not stall the SEO.
- Access to the lead You talk to the person making the technical decisions, not a relay.
- No handover gap Whoever diagnoses the problem is on the same team as whoever writes the fix.
- One point of accountability If something goes wrong, there is no question about whose job it was.
FAQ
Questions before you commission a build
Is there a plugin that already does this?
Very often, and we will tell you when there is. Paying developer rates to rebuild something a well maintained plugin already does properly is a poor use of your money, and we would rather say so than take the work.
The case for building comes up when the plugin does eighty percent of it and the missing twenty percent is the part that matters, when the plugin is abandoned or a security liability, or when the tool needs to sit on your own data in a way no general purpose plugin can.
What can you actually build?
Anything that runs on a web stack. Calculators, comparison and configurator tools, search and filtering with real logic behind it, geolocation features, quoting and pricing tools, dashboards, data importers, integrations against a third party API, and admin tooling that turns a manual process into a form.
What we are not is a native mobile app studio or a data science team. If that is the brief, another firm fits better and we will say so on the first call.
Will a tool like this be crawlable?
Yes, and this is where most bespoke tools quietly fail. The default way to build an interactive feature is to fetch everything on the client, which means a crawler sees an empty container and the tool contributes nothing to search.
We server render by default and layer the interactivity on top. The location search we built targets a term with 33k searches a month, and it stays fully crawlable for exactly this reason. If a tool is meant to earn traffic, it has to exist before the JavaScript runs.
What happens when it breaks and you are not around?
Everything is documented as it is built. Architecture, deployed code, the gotchas and a changelog. The point is that another developer can pick it up without needing us, and that has been the standard on every project.
We also design for the maintenance not existing. One geocoding layer we built falls back from a static map to a cached lookup to a one off external call, so new locations work with no code change at all. The best tool is one nobody has to touch.
How much does a custom tool cost?
Development is £90 to £100 an hour and tools are quoted as a fixed scope once we know what it has to do. The range is genuinely wide. A calculator with clear inputs is a small piece of work. A tool that derives relationships from your existing data, handles pricing logic and needs undo and redo is a much larger one.
We give you a written scope and cost before anything starts, so the number does not move mid build. Full detail on the rates page.
Can a tool actually earn links?
It is one of the more reliable linkable assets, because it is genuinely useful rather than another article. That is why the build side and the digital PR side work well together here, we can build the thing and then pitch it.
The honest caveat is that a tool costs more up front than a blog post, and it only earns coverage if the topic supports it. We will tell you when it does not.
Keep reading
Related
Book me
Describe what it needs to do.
Not how it should be built, that is our problem. Tell us what the tool has to achieve and we will tell you roughly what it takes, or point you at a plugin if one already does it.