The question hits my inbox about twice a month. Some variation: “We are evaluating Symfony consultancies for [migration / scaling / audit / new build]. What should we be asking?” The companies asking are usually mid-stage, the budget is real, and the stakes are high enough that picking the wrong vendor costs six figures in lost months.
Most buyer’s guides for this kind of work are written by the vendors. So they emphasize the things their own org happens to be strong at, and they leave out the questions that would expose their weaknesses. This essay is the opposite. It is the list of questions I would ask if I were the buyer, with the knowledge of twelve years inside Symfony engagements as both a contributor and a vendor.
The framework matters less than you think; the team matters more. The most common failure mode is not “they picked the wrong stack” but “they picked a respectable vendor whose senior people never actually showed up after the sales call.” Below are the questions that surface that gap before you sign.
Question 1: who is on the keyboard, and are they on the call?
Every Symfony consultancy has a pyramid. Senior partners do the pitch, mid-level engineers run the engagement, and the actual code is written by people you have not met. Sometimes that pyramid is honest: the seniors review architecture decisions, the juniors execute. Sometimes it is a sales tactic: the seniors disappear the moment the SOW is signed.
You cannot prevent the pyramid. You can ask which people, by name, will write the production code. Get them on a 30-minute technical call before you commit. Ask each of them:
- “Walk me through the last Symfony bug you debugged in production.”
- “What is your standing opinion on API Platform versus hand-rolled controllers?”
- “When you join a codebase, what is the first PR you usually open?”
The answers do not need to match mine or yours. They need to be specific, defensible, and grounded in real systems. If the named engineer talks in framework slogans and cannot recall a concrete incident from the last six months, the pyramid is hollow. Walk away.
Question 2: can they show you a codebase, not a slide deck?
Sales decks are works of fiction at every consultancy. They show case studies that are 80 percent accurate, retold by someone who did not write the code. The signal is not the case study. The signal is whether the consultancy can put a real, anonymized commit history in front of you.
Ask for a representative pull request from a recent engagement. A Symfony 7 migration. A Messenger-handler rewrite. A test-coverage push from 12 percent to 70 percent. Any non-trivial PR. Read the diff. Read the review comments. Read what got merged and what got pushed back.
You learn three things from one PR:
- How they write code under deadline pressure. Naming, error handling, test coverage, depth of refactor. These do not lie.
- How they respond to review. “Fixed” with no explanation is a different signal than “fixed, and added a test for the edge case raised in line 47.”
- What their internal bar looks like. If a senior at the consultancy reviewed and approved messy code, that is the bar you are buying.
Consultancies that cannot show you a PR are not consultancies. They are sales orgs with subcontractors.
Question 3: how do they disagree with you?
The expensive failures in consulting engagements are not bugs. They are the moments where the client asks for the wrong thing and the consultancy delivers it cheerfully. A bad rewrite that the team should have argued against (see What I Tell CTOs Who Want to Rewrite). A scaling pattern that does not match the load profile. A complexity layer that the team cannot maintain after the consultancy leaves.
The protection against this is a consultancy that pushes back. The way to test for it: in the discovery call, propose something that you suspect is slightly wrong. A premature microservice split. Synchronous messaging where async would obviously fit. Skipping integration tests. See what they do.
A good consultancy will say “I do not think that is the right call here, and here is why.” A bad one will say “yes, we can do that.” The polite middle, “we can do that, here are some considerations,” is acceptable, but watch it carefully. If every hard call gets routed back to you with “you decide,” you are not buying expertise. You are buying staff augmentation at consulting margins.
Question 4: what does their pricing model actually align?
There are three common pricing shapes in Symfony consulting, each with its own failure mode.
Time and materials. The consultancy bills hours. Failure mode: gold-plating. Engagements drag. The team has no economic incentive to finish on time because finishing on time means losing revenue. Good for engagements where the scope is genuinely unknown (audits, archaeology). Bad for engagements where the scope is clear and the work is mostly execution.
Fixed price. The consultancy commits to a deliverable for a fixed fee. Failure mode: cutting corners on quality once the budget starts to bite. The team’s incentive is to ship something that passes acceptance, not something that survives two years of feature work. Good for very well-scoped pieces with clear acceptance criteria. Bad for anything with unknowns.
Outcome-aligned retainer. Monthly retainer, with scope negotiated continuously, and either party can end the engagement with 30 days notice. Failure mode: lazy retainers where the team coasts. Good for long engagements where the client wants embedded expertise rather than a deliverable. The “30 days out” clause matters because it is what keeps the consultancy honest about value delivered.
There is no “right” model. There is a model that fits the work. If a consultancy proposes only one shape regardless of the work, they are running their own playbook, not yours.
Red flags I have personally seen
- The proposal has more pages on the consultancy’s own credentials than on the actual engagement plan.
- The named senior engineer is on every proposal. There are not enough hours in the week for that to be honest.
- The team will not name the cloud providers, queue brokers, or PHP versions they prefer. They claim to be “stack agnostic.” Real engineers have preferences.
- The consultancy refuses to put a junior on the engagement at all. Either juniors are not part of the firm, or the firm is hiding what the bench actually looks like.
- The retainer renews automatically. A consultancy that has to win the next month is a consultancy that ships work in the current month.
Green flags that tend to predict success
- They volunteer the names and dates of engagements that did not go well, and what they learned.
- They ask to see your codebase before quoting. Not just the README. The actual repo.
- The first deliverable they propose is small, finite, and disposable. A two-week audit. A spike on the bottleneck. Something you could cancel after with no lost asset.
- They send you their internal coding standards document, unprompted, before the engagement starts.
Where Devtide tends to fit
I will be direct: Devtide is a small, senior-heavy consultancy. I am on every engagement, by design. We do not run a junior bench because we do not staff engagements that need one. If your project is a six-month team augmentation with five engineers, we are the wrong shop. If it is a six-week monolith audit, a Symfony major upgrade, or a strangler-fig migration on a system that cannot afford downtime, we are likely the right shop.
Browse the work patterns in Strangler Fig Pattern for Symfony Monoliths and The Honest Architecture Review to see what an engagement actually looks like before you book a call.
References
- Joel Spolsky, Things You Should Never Do, Part I: on the dangers of full rewrites, the most common buy-failure mode in this market.
- Martin Fowler, StranglerFigApplication: the canonical alternative to the rewrite that most consultancies pitch.
- Symfony Certified Developer program: one credential filter, not a guarantee.
