Five signs of a competent team
- 01They ask uncomfortable questions before quoting. A good vendor first establishes what the product is for and what success looks like, and only then names a figure.
- 02They are willing to talk you out of it. If the job is solved by an off-the-shelf service for $50 a month, they will tell you, rather than sell you $30,000 of development.
- 03The estimate is broken down by stage. You can see what each contains and where you could economise deliberately.
- 04They show work in progress. A demo every two weeks is the norm, not a privilege.
- 05They discuss risk calmly. “Everything will be perfect” is a red flag, not confidence.
Red flags
- A price quoted immediately, with no questions. That means you are being sold a template, not a solution to your problem.
- Too cheap. A team costs money; half the market rate means either students or the rest appearing later as change orders.
- Refusing to show intermediate results because “it is not ready”. That usually conceals work that has not started.
- No contract, or a contract with no deadlines, no scope and no statement of code ownership.
- A single point of contact who cannot answer a technical question and will “check with the team” every time.
Four questions worth asking
Ask these of everyone on your shortlist. The answers separate candidates faster than any portfolio.
- “Who owns the code and the credentials once we have paid?” The right answer is you, entirely, repository and server included.
- “What happens if the project runs over?” A sound answer describes a mechanism rather than promising it will not happen.
- “Who exactly will work on this, and how many people?” If the team composition is a secret, the project is probably going to a subcontractor.
- “What does post-launch support include and what does it cost?” Silence about this at the start means an invoice later.
What an honest estimate looks like
A sound estimate shows three things: what is included in the base, what is priced separately, and what the final figure depends on. If the estimate is a single line reading “website development, $18,000”, you can neither compare offers nor understand what you are paying for.
Check separately whether the figures agree across places: the proposal, the vendor’s website and the contract. A discrepancy is not a detail — it tells you how the rest of the engagement will go. Our own ranges are published openly, in the Cost & timelines rubric and in the calculator on the home page.
What belongs in the contract
- Scope of work and what counts as delivery of a stage — otherwise “done” means something different to each side.
- Rights to the source code, design and data transfer to you upon payment.
- The change process: how a new request is raised and how it affects timeline and price.
- A warranty for bug fixes and a response time after launch.
- An NDA, if you are exposing internal processes or customer data.
Frequently asked questions
Do we need a specification before we start?
A hundred-page specification written before the start usually does harm: by the time it is finished the problem has moved. It is enough to understand the goal, the user journeys and the constraints — the rest is refined as you go, provided the vendor shows results every two weeks. But the scope of work does have to be fixed in the contract.
What if the vendor disappears mid-project?
Unpleasant but survivable, provided the credentials were in your name from the start. We regularly pick up projects like this: we begin with an audit of the code and infrastructure and tell you honestly whether continuing or rewriting is the better deal.
Does more expensive mean better?
No. Price reflects the level of the team and the volume of work but guarantees nothing. Look at how they build an estimate, whether they ask questions and whether they will show work in progress — that predicts the outcome better than the figure.
How do we check a portfolio?
Open the projects shown and see whether they still work, load quickly and carry live content. Ask what exactly the team did: portfolios often include projects where the vendor built a single screen.
What if a vendor has no public portfolio because of NDAs?
That is normal for enterprise and fintech work: nearly all such contracts are covered by NDAs, and some projects run white-label, where the product ships under the client’s brand. In that case check specifics rather than logos: ask to see a contract with names redacted, the systems themselves running during a call under a mutual NDA, and reference contacts. Invented experience does not survive that check.
These articles are written by engineers working on the projects — but they are not signed by name. The reason is the same one that keeps client logos off this site: nearly every project runs under an NDA or white-label, and a byline on a piece about a payment core points at the client as clearly as a logo would. Instead of names, we stand behind the text with rules — except for articles about our own open-source code, which carry the author’s name.
How we write and what we verify