Partner comparison
Choosing a Development Partner
A neutral checklist for comparing agencies, freelancers, and product studios on the things that decide how a project feels after launch: process, handover, and support terms.
Define the job before you compare anyone
Write down what you need built, what it must connect to, and what success looks like. A short brief of one or two pages is enough. Without it, every proposal answers a different question and the totals are meaningless. Include your deadline if you have one, and say whether content is ready or must be produced.
The brief is also the yardstick you will score quotes against later. If it lists the integrations, the languages, and the people who will maintain the work, a proposal that skips a line item is visible immediately rather than three months into the build.
What the brief should name
- The pages or screens you need, and their order of importance.
- Any system it must talk to: payments, stock, CRM, booking.
- Who supplies text, photography, and product data.
- The date you want it live, and the date you can accept a handover.
Agency, freelancer, or product studio
Each has a place; the mistake is hiring for the wrong shape of job. Read the four shapes below against your brief and see which one matches the amount of change you expect after launch.
Marketing agency
Sites planned around visibility
These teams build around campaigns and search. They think about how pages get found, how a launch is promoted, and how often content changes. Strong fit when the site is a marketing surface that has to move with the calendar.
General digital agency
Corporate rebuilds alongside campaigns
A wider bench: brand work, corporate websites, and the odd internal tool. Useful when your project touches several departments and you want one supplier holding the threads, less useful when the work is a single deep piece of software.
Product studio
Software is the product
Product studios work on platforms and apps where the software itself carries the business. They tend to be stronger on release cycles, testing, and long-running maintenance than on campaign traffic.
Platform specialists
One system, known deeply. A specialist will already know the platform's limits, its plugin marketplace, and how upgrades land. Worth the premium when the whole project lives inside that one system.
Freelancers
Best for smaller, well-defined pieces of work with a clear finish line. Ask about availability windows and who covers holidays or illness, because the answer shapes your delivery date as much as the quote does.
Questions about process
Ask how the work is sequenced, what you receive at each stage, and how feedback is handled. A partner who can describe their process in plain steps is easier to hold to it later.
- Sequencing and stage outputs
- What arrives at the end of discovery, at the end of design, and at the end of build. If the answer is a meeting and a folder, ask what is inside the folder.
- Testing before launch
- Who tests the site or app, on which phones and browsers, and who signs off. Ask for the list of devices rather than a promise that it is checked everywhere.
- When an integration breaks
- Payment gateways, shipping providers and booking tools change without warning. Ask who watches for that, how you are told, and whether the fix is billed as support or as new work.
- Feedback and change of mind
- How many rounds of review are included, and what happens when a comment arrives after that stage has closed. Better to know the boundary now than to argue about it later.
Ownership and handover terms
Confirm in writing who owns the code, design files, and content after handover. Confirm that domain, hosting, and repository accounts are in your name or transferred to you. If you ever want to change providers, these terms decide how painful that will be.
The practical test is simple: could a different team pick the project up next month without calling the original supplier for permission or passwords? If not, the handover terms are not finished.
Ask for this in writing, not on a call
Item
What good looks like
Source code
Delivered in a repository you control, with commit history intact.
Design files
Editable working files, not only exported images or a link that expires.
Domain and hosting
Registered to your company, with the renewal contact being someone who stays.
Documentation
A short written note on how the build is structured and where each part lives.
Third-party accounts
Licences and service accounts billed to you, or listed for transfer at handover.
Support, response times, and change work
Support should be described, not implied. A maintenance agreement without detail on response times and change pricing tends to produce disputes rather than fixes, because everyone remembers the agreement differently once something is broken.
Response times by severity
Ask for a target measured in hours or working days for each level: something blocking sales, something degraded, something cosmetic. A single blended number hides the cases that matter.
Bug or change request
A bug means the build does not do what was agreed. A change request means you now want something different. Write the line between them down, and ask how each one is priced.
Updates and security patching
Platform releases and library updates arrive on someone else's schedule. Ask how often patches are applied, who tests them, and what happens if an update breaks a custom feature.
Cost structure and what changes it
Compare quotes by line item rather than by total. Two proposals that land within a few thousand of each other can cover very different amounts of work, and the gap usually hides in testing, content, or integrations.
One-time lines
- Discovery and scoping, including the brief itself.
- Design, from first layout to approved screens.
- Build, split by page type or feature where possible.
- Integrations: payments, shipping, booking, CRM.
- Content production, if text and photography are not ready.
- Testing across devices, browsers, and the checkout flow.
Recurring and variable
- Hosting, which continues for as long as the site is live.
- Platform or plugin licences, billed yearly in most cases.
- Support hours, either a monthly allowance or pay-as-used.
- Third-party services such as email or search tools.
- Change work triggered by new requirements after sign-off.
Ask what assumptions each quote makes and what would trigger a change order. A cheaper proposal that leaves out integration testing is not cheaper overall, and a proposal that lists its assumptions is easier to compare line by line.
Data handling and compliance expectations
If the project touches personal data, ask how it will be stored, who can access it, and how it is deleted. Singapore businesses should expect to address obligations under the PDPA, and a partner should be able to discuss that without being prompted.
Payment handling should stay with established providers rather than being built from scratch. Mobile app projects also need store privacy disclosures before release, and those disclosures have to match what the app actually collects.
Reasonable planning questions
- Where personal data is stored and who holds the keys.
- How a deletion request is handled once the site is live.
- Which parts of the build sit with an established payment provider.
- What the app store listing says it collects.
Checking references and track record
Ask for two or three projects similar to yours and, where possible, speak to those clients. Ask what went well and what did not. Company size and directory placement are weaker signals than a specific, relevant build and a client willing to talk about it.
Use the live product
Open the sites and apps they name on a phone, on a slow connection if you can. Check page speed, mobile behaviour, and the checkout or booking flow from a user's point of view.
Ask the awkward question
What would you do differently on that project now? A partner with a straight answer has usually thought about their own work rather than only their pitch.
Red flags in proposals
These are not automatic disqualifications. They are points that need a clear answer before you sign anything, because each one tends to surface as a delay or a dispute once the work is underway.
-
Vague scope that describes outcomes instead of deliverables. If you cannot count what you are buying, you cannot check it later.
-
No support terms at all, or a monthly figure with nothing behind it about response times and what counts as included.
-
Pricing that arrives as one number with no breakdown, so you cannot tell which part of the work is thin.
-
Promises about traffic, ranking, or revenue outcomes. No one controls those, and a proposal that leads with them is selling something other than development.
-
Ownership language that stays unclear, or a team that cannot name who will actually do the work.
-
A quote that arrives without a single question about your requirements, which usually means the brief was not read closely.
Score against the brief, not against each other
Put each proposal beside your own brief and mark what is covered, what is assumed, and what is missing. The gaps are more useful than the totals.
Getting to a decision
Score proposals against your brief, not against each other. Weigh process clarity, relevant experience, handover terms, and support detail alongside price. Then ask one final round of questions to the two strongest.
A partner who answers precisely at this stage is usually the one who will answer precisely during the project. Precision in a proposal is a small sample of how the team communicates when the work is difficult.
Score against your brief
- Process clarity: can they describe the sequence in plain steps?
- Relevant work: have they built something shaped like yours?
- Handover terms: do you end up owning the accounts and files?
- Support detail: are response times and change pricing written down?
- Price: read against the line items, not against the total alone.
Questions people ask before they compare quotes
Should I ask for a fixed price or an hourly rate?
Either can work. A fixed price suits work you can describe precisely and protects you from overruns on that scope. An hourly rate suits exploratory work where requirements will move. Whichever you choose, ask what is excluded and what triggers a change order.
How much should I expect to be involved during the build?
Enough to review each stage and answer questions about your own business. Projects slow down when feedback arrives late or when the person who can approve changes is not in the room. Ask how feedback is collected and how quickly you are expected to respond.
What happens if the partner stops trading?
This is exactly why ownership and handover terms matter. If the repository, domain, and hosting accounts are in your name from the start, a new team can continue the work. If they are not, recovery becomes a negotiation.
Do I need a custom build or a platform store?
It depends on how far your needs sit from what an established platform already does well. Stores and site builders cover a lot of ground quickly; custom work earns its cost when your rules, integrations, or workflows do not fit those patterns. Our guide to e-commerce store builds and platform choices walks through the trade-offs.
How long should support last after launch?
Long enough to cover the first months of real traffic, when small issues tend to appear. Many teams start with a short support period after launch and move to a monthly agreement once the site has settled. What matters is that the terms are written down rather than assumed.
This resource is maintained by ViewCyber Digital. See how we research these guides if you want to know which sources sit behind the checklist, or read the mobile app development guide for the release side of the same decisions.
Where to go next
Send a question
If a proposal in front of you raises something this page does not cover, write to us and describe the situation. We answer questions about comparing partners and scoping work, and we do not sell from that inbox.
Email: [email protected]
Phone: +65 6707 0497
Monday–Friday, 9:00 AM – 6:00 PM
Liakollveien 28B, 1259 Oslo, Norway