Flash Web Center provides Drupal services in five areas — development, architecture, theming, upgrades and ongoing maintenance — for organisations that already depend on Drupal or are deciding whether to. Based in Austin, Texas, working remotely with teams anywhere. With 20+ years of experience and 27+ contributed Drupal projects, the work is grounded in code that is public and can be read before you commit to anything.
Start with the problem, not the service name
Most people arriving here have one of a small number of problems. This is the honest mapping between them and what actually helps.
| What is happening | What it usually needs |
|---|---|
| The site works but every change is slow and expensive | A code review of the custom modules, then targeted refactoring |
| A major version upgrade is due and nobody wrote the custom code | An upgrade assessment: contributed module inventory, custom code audit, sequenced plan |
| Pages are slow after hosting and caching were already tuned | Performance work in the code and render layer, not more infrastructure |
| Several sites are being maintained separately | An architecture decision about consolidation before any build |
| The design exists and the site does not | Theming and site building against a settled content model |
| Nothing is broken and nobody is watching it | Maintenance: security releases, backups, monitoring |
Drupal development
Custom modules, entity types, access rules, queue workers and integrations — the behaviour that configuration and contributed modules cannot express. The working rule is that the cheapest custom code is the code not written: configuration first, a well-maintained contributed module second, custom code last and deliberately.
The detail of how that is approached, including what belongs in a module versus a theme and what makes custom code survive an upgrade, is on the Drupal development services page. The role itself, and how to evaluate someone doing it, is on the Drupal developer page.
Architecture and technical review
The decisions that are expensive to reverse: one multisite or several installs, coupled or decoupled, the content model, and where caching and invalidation live. This is the work to buy before a large build, and the work to buy when an estate has grown without a plan.
It also covers independent review — reading an architecture somebody else proposed and saying plainly what it will cost to live with. The Drupal architect page sets out how those decisions are made and what the deliverable contains.
Theming and front end
Custom themes and sub-themes, Twig templates, component structure, accessibility and front-end performance. Also theme rescue: existing themes that fight Drupal's theme layer, carry a stylesheet nobody can safely delete, or fail keyboard and screen-reader testing.
The approach, including why core tells you not to sub-theme Olivero casually, is on the Drupal themer page.
Upgrades and migrations
Drupal 7 and older sites moving to a current version, and major version upgrades on sites that cannot stop publishing. The first deliverable is always the same and is deliberately unglamorous: an inventory of every contributed module with the core versions it declares support for, every custom module with an assessment of what breaks, and a sequence that keeps the site deployable throughout.
Migrations from other platforms are the same discipline with a different source: map the content model first, migrate iteratively, and validate against real content rather than samples.
Performance
Performance work starts with measurement and usually ends in the code rather than the server. Common findings: render arrays that declare no cache tags so nothing can be cached safely, caching switched off years ago to work around a bug that is still there, views doing work that belongs in a query, and front-end payloads that no page uses.
Two related write-ups are five simple ways to make any website faster and, for sites behind a CDN, how Drupal, Cloudflare Purge and long cache TTLs work together.
Maintenance
Security releases applied promptly, dependency updates through Composer so advisories actually reach you, backups that have been restored at least once, and someone reading the logs. Most Drupal security incidents are unapplied updates rather than novel exploits, which makes this the least interesting and highest-return service on the list.
Why this shop
The strongest evidence available is public. There are 27 contributed modules and themes listed on the portfolio — among them the Solo theme, Paragraphs Bundles, Module Matrix, Selectify, UtiliKit, Cloudflare Purge and the Vanilla Views set — all of them readable on drupal.org, issue queues included. Maintaining contributed code means every core release is met on someone else's sites as well as your own, and that is a different kind of exposure to Drupal's changes than agency project work provides.
The professional history behind that, including a nine-site multisite consolidation and architecture lead work on federal government Drupal platforms, is on the resume.
How an engagement runs
- A conversation. What the site is, what is prompting the work, what has already been tried.
- A written scope. What is included, what is explicitly not, and what the deliverable is. Fixed scope wherever the work can be defined; time-based where genuinely exploratory.
- Work in smallest-risk-first order, so the site stays deployable rather than entering a long period where nothing can ship.
- A written handover. What changed, what was deliberately left alone, and what debt remains. A handover that exists only in someone's memory is not a handover.
Common questions
Do you work with our existing team or replace them?
Both arrangements are normal. Working alongside an in-house team — review, difficult pieces, upgrade planning — is often the better value, because your team keeps the knowledge.
Can you take over a site somebody else built?
Yes, and it starts with reading it rather than proposing a rebuild: what is configuration, what is custom, how far behind the contributed modules are, and where the previous team took shortcuts. Most of what looks irrational in an inherited codebase turns out to have had a reason.
What do you need from us to give an estimate?
Your Drupal version, your PHP version, roughly how many custom modules you carry, and what is prompting the work. That is usually enough to say whether the job is small, and enough to scope a review if it is not.
Do you do one-off work or only retainers?
Both. A fixed-scope code review or upgrade assessment is a common first engagement precisely because it does not commit either side to anything larger.
Getting started
Contact Flash Web Center to discuss your Drupal needs:
- Phone:
- Email:
- Written estimate: request a quote
- Talk it through first: contact us online
If you are still deciding which of these you need, describe the symptom rather than the solution. Half the time the useful answer is smaller than the one people arrive asking for.