What we are good at, spelled out
Nine areas we take work in, the stack we actually use on them, and the artifacts you end up holding. If something is not here, we will say so rather than learn on your budget.
Nine things we do well
| Area | What that means in practice |
|---|---|
| Data collection | Catalogs, prices, listings, directories, public records and search results — paginated, rate-limit aware, with parsers that fail loudly instead of writing bad rows. |
| Cleaning & enrichment | Field normalization, deduplication, cross-source matching, filling gaps from public data, and one consistent output shape. |
| Pipelines & scheduling | Runs on a schedule, retries on failure, logs what happened, alerts a human when it breaks, and can be re-run for a single batch. |
| Integrations | n8n, Make and Zapier where they fit; direct API work where they do not. Orders, notifications, sheets, CRMs, payment events. |
| Site generation | Catalog and content pages produced from one data source, with pre-publish quality gates and static output that is cheap to host. |
| Technical SEO | Crawl and index diagnostics from Search Console, canonical and redirect hygiene, internal linking, pagination, sitemaps. |
| Structured data & AI visibility | Schema that matches the page, entity consistency across the site and its profiles, and pages written so a machine can quote them correctly. |
| Performance | Image and font weight, render blocking, layout shift, caching — measured before and after on the real URLs. |
| Migrations | Host, platform or stack moves with the URL map preserved, redirects in place and the index checked afterwards. |
What we build with
Chosen for staying alive without a subscription: plain files, boring databases, standard tooling.
Python · PHP · JavaScript · SQL
Python for collection and pipelines, PHP for server-rendered sites and forms, JavaScript only where a page needs it.
Django · React · plain HTML/CSS
Framework when the product earns it; static HTML when it does not. No build step is a feature, not a limitation.
MySQL · SQLite · CSV/JSON
Your data ends up somewhere you can open and export, not locked inside a tool only we can run.
Linux · nginx · Cloudflare · cron
Container or plain systemd services, CDN in front, TLS always strict, backups you can restore from.
n8n · Make · Zapier · webhooks
Low-code where a team will maintain the workflow; code where the logic is too specific to live in a node graph.
Search Console API · sitemaps · schema.org
We work from the data the search engine is actually showing you, page by page.
Not on this list, and why it matters: we do not do mobile app store submissions, paid media, or design-as-illustration work. Saying no early is cheaper for both of us.
What you receive at handover
Not a screen-share walkthrough that vanishes. Four things, written down, that survive us.
repo/ source, readable history collector/ scheduled entrypoint clean/ transformation rules store/ schema + migrations run.sh start · stop · re-run batch
daily 04:40 automatic manual ./run.sh --once retry ./run.sh --batch 12 fail alert mail + tail of last run cron crontab line, verbatim
source Search Console export window same dates, both runs granularity page level, not a score stored in your account, not ours
what will break first what we did not do what we would do next what it would cost
How a scope becomes a quote
You send the sample
A URL, an export, or two screenshots of the system involved. This is the only thing we need to price the work.
We write the scope
Included, excluded, assumptions, what we need from you, delivery window, one fixed number and what triggers a change to it.
You approve, we build
Half up front. You follow progress on a staging URL. Nothing is marked done until it has been exercised, not merely written.
The sheet we would be scored on anyway
Buyers evaluating studios use a weighted scorecard, and they are right to. Here are the criteria, the evidence to demand for each, and where we currently stand, including the rows where we are not the best answer. Rate each one yourself; we would rather lose on a visible line than win on a vague impression.
| Criterion | Evidence to demand from anyone | Where ours is |
|---|---|---|
| Working code, not slides | A repository you can open, or a module walked through live | Walkthrough on a call, including the parts that are ugly |
| Works in tools you already pay for | Which platform, and what you do when we are gone | n8n, Make or Zapier when you can maintain them; plain scripts when the logic outgrows them |
| Who owns the outcome | The clause, plus repository access from day one | Yours from the first commit — spelled out, because in the UK and EU the default is the opposite |
| What happens when it breaks | The alert path, the run log, and who is paged | Alerts into a channel you already read, naming the step that failed; run log readable without us |
| Can you reach the person doing the work | Who answers your email, and their name | Yes — owner-operated, no account layer. Counterweight: one person means finite capacity, so we say no to dates we cannot hold |
| Pricing model | One fixed number for a written scope, or a formula you can audit | Fixed scope, fixed price, published ranges, milestones above $3,000 |
| Do they say no | Ask what they will not do | No backlink packages, no ad management, no ranking guarantees, no scraping behind logins, no invented case studies |
| After handover | A runbook, and a named way to get help | Written handover by default; ongoing monitoring as the optional care plan |
Where we are not the best answer
- 24/7 cover or a phone line: not something one person can honestly sell.
- Design-led brand work: we build clean, fast sites, not award-winning art direction.
- Being the cheapest: the low end of this market prices scrapers at $100, and it shows.
- Large parallel projects: two builds at once is our realistic ceiling.
How to weigh these
If the work is revenue-critical, weight ownership, failure visibility and handover highest; those are the rows that hurt later. If it is a one-off, weight price and speed, and accept less documentation.
Ask every vendor for the same three pieces of evidence: one repository, one run log, one clause. Answers are cheap; artifacts are not.