Feature — Studio doctrine
We build software that is meant to last, not software that ships and disappears.
§ 02
Introduction
A studio for the parts of a product that outlast the launch.
Cinderblock is an independent technology and digital production studio. We work with founders, in-house engineering leaders and design directors who need a partner that can hold the long view of a product without losing the discipline required to ship it. Our engagements are quiet, considered and small in number by design.
We are equally comfortable writing production code, restructuring a legacy platform, or sitting in the strategy room where the roadmap is decided. What we do not do is deliver work that only looks good on the day it is handed over. Every component we ship is expected to be legible, adjustable and defensible six months and six years from now.
§ 03 · Capabilities
Four disciplines, one team.
The studio is intentionally shaped around four practices that reinforce each other. We staff each engagement across these disciplines rather than handing the work between separate silos, which is how details tend to get lost.
- i.
Engineering
Product engineering, platform work, backend services, infrastructure and the long tail of maintenance that keeps a product healthy.
- ii.
Design
Product and interface design that treats structure and readability as the first-order concern, with visual craft on top.
- iii.
Digital production
Content operations, editorial systems, media pipelines and the coordination that turns a design system into a working publication.
- iv.
Technical consulting
Architectural review, second opinions, hiring support and the kind of quiet advisory work that shortens someone else's roadmap.
§ 04
Index of services
A working list of what the studio can be asked to do.
Custom software development
Bespoke systems written for one organisation, from the data model outwards.
Web application development
Interactive product surfaces built to hold real users under real load.
Website development
Public-facing sites — editorial, marketing, product — with content operations behind them.
UI and UX design
Structure, hierarchy, typography and interaction, before any decorative pass.
Cloud infrastructure
Provisioning, observability and cost discipline on AWS, GCP and comparable platforms.
API and system integrations
Connecting internal systems, third-party services and legacy data sources without shortcuts.
Business process automation
Removing manual work from operational teams with reliable, auditable pipelines.
Quality assurance and testing
Automated tests, manual exploration and pre-release verification treated as engineering.
Data solutions
Warehousing, ingest, transformation and reporting for teams that need to trust their numbers.
System modernisation
Careful, incremental replacement of aging systems without a big-bang rewrite.
Application maintenance
The unspectacular, ongoing work of keeping a live product healthy.
Cybersecurity consulting
Reviewing posture, threat surfaces and controls appropriate to the product's risk.
Technical consulting
Second opinions, architectural review and hiring support for internal teams.
Digital product development
End-to-end product work, from discovery to launch to iteration.
Creative digital production
Editorial and campaign work delivered through modern content and design systems.
§ 05
Technology
Deliberate tools, chosen per project.
We favour boring, well-understood technology in the parts of a system that carry the most risk. Novelty is reserved for places where it earns its keep.
Languages
TypeScript · Python · Go · Rust for critical paths · SQL
Front-end
React ecosystems · Next.js · TanStack · design systems · accessibility
Back-end
Node · FastAPI · Postgres · Redis · queues · event streams
Cloud
AWS · GCP · Cloudflare · Terraform · container orchestration
Data
Warehouse pipelines · dbt · analytics events · reporting surfaces
Delivery
CI, review environments, incident tooling, on-call practices
§ 06
Method
Five movements from a first conversation to a working system.
Step 01
Listen
We spend the first weeks understanding constraints, incentives and prior decisions before proposing anything of our own.
Step 02
Frame
A short written proposal establishes shape: what is being built, what is deliberately not being built, and how success is judged.
Step 03
Build
Small, reviewable increments in a shared repository. Nothing waits three months to be seen by the client.
Step 04
Harden
Automated testing, load work, security review and operational drills before anything is called finished.
Step 05
Steward
The engagement continues in a lighter form: maintenance, monitoring and the occasional new capability.
Plate 07 — On structure
§ 07 · Sectors
Sectors we have worked across.
The studio is generalist by policy — engineering craft transfers well across industries when it is grounded in the specifics of the organisation. Work to date has spanned:
- —Media, publishing and editorial
- —Fintech and payments infrastructure
- —Health technology and clinical tools
- —Marketplaces and two-sided platforms
- —Logistics, operations and internal tooling
- —Cultural institutions and non-profits
- —Creative agencies and production studios
- —Education and learning platforms
§ 08 · Production
Digital production, seriously.
Modern production is a technical discipline. A publication, a campaign or a product surface is only as good as the systems that move content and code from draft to distribution. We build those systems as first-class engineering work.
That means editorial workflows with real permissions and audit trails, media pipelines that survive scale, design systems that stay consistent across teams, and delivery pipelines that respect the calendar of the people using them.
§ 09 · Rationale
Companies work with us when the cost of getting it wrong is higher than the cost of doing it carefully.
Continuity
The engineer who wrote the code is the engineer who supports it. There is no handover cliff.
Legibility
Code, decisions and infrastructure are documented so that any competent team can pick them up in the future.
Restraint
We routinely recommend building less. The best systems tend to be the ones we managed not to over-engineer.
§ 10 · Craft
Quality and security are delivery requirements, not review steps.
Quality principles
- Small, reviewable changes — no long-lived branches, no invisible work.
- Automated testing at meaningful boundaries — not vanity coverage.
- Observability from day one — logs, metrics and traces treated as product features.
- Documentation as the artefact — decisions written down so they survive the team.
Security principles
- Least privilege by default for humans and services.
- Dependency hygiene — pinned versions, regular audits, reproducible builds.
- Encryption in transit and at rest as a baseline, not an upgrade.
- Documented incident procedures proportional to the product's risk profile.
§ 11 · Lifecycle
The shape of a typical engagement.
Engagements vary in scope, but nearly all of them move through the same recognisable phases. The proportions shift; the sequence usually does not.
- Week 0
Discovery
A short paid discovery reads existing code and constraints. We deliberately avoid promising anything before this.
- Weeks 1–2
Framing
A written proposal sets the shape of the work, the risks, and the definition of done.
- Weeks 3–N
Delivery
Iterative build with weekly demos and a working environment the client can use at any time.
- Pre-launch
Hardening
Security review, performance work, incident dry-runs and documentation before anything is called live.
- Post-launch
Stewardship
Ongoing maintenance, monitoring and occasional new work, on terms that suit the client's cadence.
Plate 12 — Review in progress
§ 12 · Advisory
Technical consulting for internal teams.
A significant part of the studio's work is advisory. In these engagements we do not necessarily write the code — we help the people who will. This typically takes one of a few recurring shapes:
- Architectural review
- A structured look at a system's shape, its failure modes and the decisions that led to its current form.
- Second opinion
- An independent read on a proposed rewrite, migration or vendor selection, delivered as a written document.
- Hiring and org support
- Practical help writing job specs, interviewing engineers and shaping small teams around the work they need to do.
- Fractional engineering leadership
- Filling a senior engineering role for a defined period while a permanent hire is found.
§ 13 · Reference
Frequently asked
Questions the studio hears often.
01What kind of projects does the studio take on?read →
Custom software, web platforms, internal tools, integrations, cloud infrastructure work and long-running product engagements. Engagements usually begin with a short discovery phase before any implementation is scoped.
02Do you work with existing engineering teams?read →
Yes. Many engagements involve joining an existing team as a specialist function — for example, taking responsibility for a specific service, platform migration, or design system — rather than delivering in isolation.
03Which technologies do you use?read →
Technology choices are made per project. In practice this most often means TypeScript, modern JavaScript frameworks, Python or Go on the server, PostgreSQL and managed cloud services on AWS, GCP or comparable providers.
04How do you handle security and privacy?read →
Security is treated as a delivery requirement rather than a later review step. Every project applies least-privilege access, dependency review, encrypted storage, audit logging and a documented incident procedure appropriate to its risk profile.
05How do we start a conversation?read →
Send a short description of the project to the studio email address shown in the Contacts section. A member of the studio will review the outline and reply with proposed next steps.
§ 14 · Correspondence
Speak with the studio.
Correspondence is handled by email. A short description of the project, its context and any relevant constraints is enough to begin a conversation.
- Studio
- CINDERBLOCK PRODUCTIONS LTD
- nicholascooper1957@gmail.com
- Domain
- cinderblockpictures.com
- Language
- English
— end of issue.
A brief tour of how the studio thinks and works. The other pages in this site expand on each of these themes in greater depth: the studio itself, the specific services on offer, and how correspondence is handled.
