How to choose a software vendor: what to read, what to ask, and our answers

You cannot assess a software supplier by looking at the work, because the work does not exist yet. What you can assess is the paperwork: how precisely they describe what they intend to build, how they structure payment against it, and what position you are left in if the relationship ends.

What a proposal must contain

Treat the proposal as the specification it will become. Every item below that is absent is a decision deferred to a moment when you have less leverage.

Seven questions, and what the answers tell you

1. What comes out of discovery, and do I keep it?

   A written process specification, a data model and acceptance criteria: documents still useful to a different supplier. If discovery produces only a quote, you bought a sales process.

2. What have you built in a business like mine?

   Domain detail is what you are listening for. Someone who has built for manufacturing knows about scrap, lot allocation and stage-based progress billing without being told.

3. Are your price bands published?

   Published bands make quotes comparable and give you a reference point before any conversation. If pricing appears only after a meeting, ask what the range is and how it is derived.

4. Who owns the source code, and from when?

   The answer should be "you, from the first commit, in your own repository." An assignment that takes effect at final payment is much weaker than possession throughout.

5. When do I see software running?

   A clickable prototype in the first two weeks and a working module in weeks 2 to 4, which is the window we publish. A supplier who shows nothing for four months is asking you to fund a guess.

6. What does maintenance cost and cover?

   A percentage of build cost, with response times and included hours written down. Our tiers are 12%, 18% and 25%, explained in the maintenance guide.

7. What happens if we part company in two years?

   Ask for the handover contents explicitly: source, schema, deployment steps, environment variables, credentials. A supplier who has not thought about this will improvise the exit at the worst time.

The eight clauses that decide your position

• Scope and acceptance: scope referencing the module list, and acceptance criteria your own staff can test, not the supplier's opinion that the work is complete.
• Milestones and payment: each payment following something you can open and use. Front-loaded schedules move all the risk to you.
• Intellectual property: full assignment of source, schema and design assets, no per-user licence, no expiry, and no carve-out for a "core platform" you would only be licensed to use.
• Data: where production data is stored, who holds credentials, how access is logged, and what happens to copies at the end.
• Change control: how a change is requested, estimated and approved. Without it, either every change is an argument or none are priced.
• Warranty: a defined period after go-live during which defects are fixed at no charge, with defect distinguished from new requirement.
• Maintenance: the tier, price, response times, included hours, and whether it is optional.
• Termination and handover: notice period, what is delivered on exit, and confirmation that ending the relationship does not affect your licence or your access to the code.

Answers that should stop you

These are about answers, not about whoever gives them. Each is a signal to slow down and ask a follow-up.

Paying for software does not make you its owner

This is the most expensive assumption in the market, and nearly every first-time buyer holds it: that an invoice transfers a copyright. In most jurisdictions it does not, and the default runs the other way.

In the United States the Copyright Office is explicit. A work commissioned from an independent contractor qualifies as a work made for hire only if it falls into one of nine listed categories and both parties sign a written agreement saying so. The nine are a contribution to a collective work, part of a motion picture or audiovisual work, a translation, a supplementary work, a compilation, an instructional text, a test, answer material for a test, and an atlas. Custom business software is not on that list. Without a signed assignment the developer holds the copyright, and any transfer of copyright ownership has to be made in a writing signed by the owner.

UK guidance states the same default in one sentence. For a commissioned work, "the first legal owner of copyright is the person or organisation that created the work and not you the commissioner, unless you otherwise agree it in writing." A developer working under a contract for services "will usually retain copyright in any works he produces, unless there is a contractual agreement to the contrary."

Supplier-side guides say it plainly too. One UK development firm's buyer guide records that "most custom-built applications default to licensing rather than ownership," and answers the direct question in the negative: in most jurisdictions the developer keeps the copyright unless the contract explicitly assigns it to the buyer.

So the sentence "you will own the software" in a sales deck is not a legal position. It is a summary of a clause that may or may not exist, may or may not be effective yet, and may cover less than you think.

Four things "ownership" turns out to mean

The second row is the one that catches people, because it sounds reasonable. It is not the same as possession. If rights transfer only on final payment, every disagreement in the last month of the project is negotiated with your entire system as the stake.

What a proper transfer has to include

An assignment clause with nothing behind it produces a zip file nobody can start. Published handover guidance converges on the same list, and it is worth writing into the contract as a deliverable rather than assuming it:

• The codebase with its version history, in a repository you control, not a snapshot emailed at the end.
• Build scripts and environment configuration, so the application can be compiled and run outside the supplier's machine.
• Infrastructure as code and environment documentation, covering how each environment is provisioned.
• The database schema and migration scripts, including the relationships, not only a data dump.
• A deployment procedure that installs the system from scratch and can be followed by someone who was not there.
• Documentation of configuration, integrations and known constraints, plus an architecture overview.
• A working build pipeline and a test suite that passes at the moment of handover, verified before you accept delivery.
• Account and credential transfer: repository, servers, domain, third-party services and API keys, with a rotation plan for every secret the supplier has seen.
• The open issues backlog, so you inherit the known problems rather than discovering them one at a time.
• Knowledge transfer sessions with the people who actually wrote it, scheduled and paid for as part of the exit rather than requested as a favour afterwards.
• A defined warranty and support period that survives the handover itself.

Two honest caveats. First, no assignment covers third-party open source libraries; those stay under their own licences, which is normal, and what you should ask for is the licence inventory rather than an impossible promise. Second, if the supplier built on their own internal framework, that part is usually licensed rather than assigned. That can be acceptable, but only if the licence is perpetual, transferable and royalty-free, and only if you know what happens when they stop maintaining it. The test that settles all of this is a cold start, described in what source code delivery actually includes: hand the package to an engineer who did not build the system and see whether it runs.

The questions, and our answers

One of the more thorough due diligence checklists published in this market runs to 35 questions across process, team competence, pricing, maintenance and security, and risk and exit. It is a useful list, and it ends where most supplier-published checklists end: the questions are printed, the firm's own answers to them are not. A question list is generic. An answer list is a position, and a position can be quoted back at you two years later, which is exactly why they are rare.

Ours are below, grouped the way a buyer actually works through them. The reason we can answer the ownership and exit block without hedging is structural rather than virtuous: a one-time fee, source code delivered at each milestone, a perpetual licence, unlimited users, and maintenance that is optional. A supplier whose revenue depends on your subscription cannot answer "what happens if I want to switch vendors" honestly, because the honest answer costs them the account. Where our own answer is weak, it is marked weak rather than dressed up.

Ownership and exit

Price and scope

Team and continuity

Data and compliance

After delivery

Where our answers are weak

Every supplier's answer list has soft spots, and publishing only the strong ones is how you end up with a page nobody believes. These are ours, in roughly the order a careful buyer finds them.

• No customer logos, testimonials or reference list. Six systems are named on our cases page, and three of those are our own product lines rather than customer builds. Other installations are unnamed at the customer's request, and we ask permission before naming anyone. Against a supplier with forty logos on a wall this is a real disadvantage. If you are at a serious stage you can ask us to approach a customer for a reference call; whether it happens is their decision, not ours.
• No security certification. Neither ISO 27001 nor SOC 2. This fails some tender gates outright, and no amount of contractual control substitutes for a certificate when the rule is a certificate.
• No 24/7 cover and no uptime guarantee. If a stopped system at 03:00 costs you money, you need a supplier organised around that, or an internal team on call.
• A small studio has no bench depth. Key-person risk is real here. It is mitigated by your ownership position rather than by our headcount, which is a genuine mitigation but not the same answer a large agency can give.
• Türkiye is outside the EU adequacy list. An EU buyer takes on standard contractual clauses and a transfer impact assessment that an EU-based supplier would not require. That is paperwork rather than a barrier, but it is paperwork you would not otherwise have.
• No vendor partnerships. Independence is why we can recommend against building, and it also means no partner discounts and no partner-channel escalation into any large vendor.
• No money-back guarantee. The protection is milestone-by-milestone exit with the deliverables already in hand, which is a different shape of protection and worth comparing directly against whatever else is on your shortlist.
• We are not the fastest route to live. A packaged product is running today. Where breadth per euro matters more than fit, buy the package: see packaged versus custom and the published numbers in the 2026 ERP pricing comparison.
• The brand is younger than the work. Systems have been built and run since 2019, but KodDelta as a name is new. A supplier-longevity check against the company name returns a shorter history than the track record, and it is better to hear that from us than to find it and wonder.

Reference calls: what to actually ask

References are pre-selected, so asking whether they were satisfied wastes the call. Ask what was in the original scope that is not in the finished system and why; what the first serious disagreement was and how it ended; how long support takes to reply now; and whether they could move to another supplier next month. The last one tells you whether the handover promises were ever real.

Also work out what a missing reference means. A supplier who names no customers at all may have a thin track record, or may simply build private internal systems for companies that decline to be named. The two look identical from outside, and the way to separate them is to ask for a call rather than for a logo.

If you have a technical lead, have them check four things

Ask to see the repository during the prototype phase and have your own engineer look at four things: commit history (frequent and described, not occasional large dumps), automated checks (tests, linting and a staging deployment on each change), the data model (normalised tables with real keys and constraints, rather than everything stored as text), and security posture (input validation, no credentials in client-side code, production access controlled and logged).

Making competing quotes comparable

Two quotes differing by a factor of three usually describe two different systems. Send every supplier the identical numbered module list, role list, named integrations with their direction, and record counts, then compare line by line. What remains is a genuine difference in approach worth asking about. The drivers behind it are in what determines custom software cost, and for a supplier abroad the cross-border checks are in the nearshore risk guide.

Sources

• Questions to ask a software vendor before signing (pragmaticcoders.com): the 35-question checklist referenced above.
• Circular 30, Works Made for Hire (copyright.gov): the nine categories, the signed-agreement requirement, and the rule that transfers must be in writing.
• Ownership of copyright works (gov.uk): the commissioner is not the first owner unless agreed in writing.
• Software source code ownership (talkthinkdo.com): the default to licensing rather than ownership, and a handover checklist including a passing test suite.
• Source code ownership and handover (virtuoustechlogic.com): repositories, infrastructure as code, environment documentation, key rotation, account transfer and the open issues backlog.
• Adequacy decisions (commission.europa.eu): the current list, which does not include Türkiye.
• Standard contractual clauses (commission.europa.eu): the pre-approved model clauses used as a transfer ground.
• Custom web application development (scnsoft.com): $70,000 to $300,000 for a customer-facing web portal, $50,000 to $250,000 for an average enterprise web app.
• Dealer portal (orderwerks.com): published pricing from $100 per month with a 2 to 4 week setup.
• KodDelta pricing bands, delivery times and maintenance tiers.

Third-party pages were checked in August 2026 and their owners change them without notice; follow the link before relying on a figure. This page describes contract practice, not legal advice, and copyright rules differ by jurisdiction. Company and product names belong to their respective owners; KodDelta is not a partner or reseller of any firm named here.

Our answers to every question above are on this page rather than behind a call, and the underlying commitments are published too: bands and delivery times on the pricing page, how we work on the about page, the systems we are allowed to name on the cases page, and a scoped response through the quote form. If your shortlist contains suppliers who will not answer the ownership and exit block in writing, that difference is worth more than any of the numbers.

Frequently asked questions

What should a custom software proposal contain?

A numbered list of modules and the workflows inside each, the user roles and what each can see, named integrations with the direction of data flow, the migration volume, written acceptance criteria, a milestone schedule with dates, the payment split, and the maintenance terms after go-live.

Do I own the source code because I paid for the development?

Not automatically. In the United States, a work commissioned from an independent contractor is a work made for hire only if it falls into one of nine listed categories and both parties sign an agreement saying so; software is not among the nine, so the contractor holds the copyright unless it is assigned in a signed writing. UK guidance states the same default: the first legal owner is the party that created the work, not the commissioner, unless agreed otherwise in writing. The assignment clause transfers ownership, not the invoice.

What must a source code transfer actually include?

The codebase with its version history in a repository you control, build scripts and environment configuration, the database schema and migration scripts, a deployment procedure someone else can follow, documentation of integrations and known constraints, a working build pipeline and a passing test suite, transfer of the repository, server, domain, third-party accounts and API keys with a key rotation plan, the open issues backlog, and knowledge transfer sessions with the people who wrote it.

What is the clearest red flag when evaluating a software supplier?

A firm price and delivery date given before anyone has looked at how you actually work. A number produced without seeing your spreadsheets, your exceptions and your record volumes is not an estimate of your project. It is a template, or an opening position that will be revised once work begins.

Which contract clauses matter most in a software agreement?

Eight: scope with written acceptance criteria, milestone payment terms, intellectual property assignment, data location and access, the change control process, the warranty period after go-live, maintenance terms and pricing, and termination with a defined handover. Read those eight before anything else.

Why does a working prototype in week two matter?

Because it converts a written specification into something your staff can click and object to. Objections in week two cost a conversation; the same objections after four months of unseen development cost a rebuild. It is also the cheapest test of whether a supplier can actually ship.

What happens to our system if KodDelta stops trading?

It keeps running, and another team can take it over, because the source code, the schema, the documentation and the deployment procedure are already in your hands from the first milestone rather than at the end of the project. That is a property of the delivery model rather than a claim about our stability, which is the point of it.

What happens if we stop paying for maintenance?

The system keeps running and you keep the code. Maintenance is an optional annual agreement at 12 to 25% of build cost and buys developer time, not your right to use software you already own. A subscription supplier cannot give that answer, which is why it is worth asking every supplier on your shortlist.

Does KodDelta publish customer references?

Not in the usual form. Six systems are named on our cases page, and the page states what each one is: three are our own product lines, one is still in development, and two were built for a single company. We publish no customer logos, testimonials or contactable reference list. Other installations are unnamed at the customer's request, because they are internal operational systems their owners treat as a competitive matter. Against a supplier with a wall of logos this is a genuine disadvantage, and we would rather say so than pad the page.

Is KodDelta ISO 27001 or SOC 2 certified?

No. We hold neither certification and will not imply otherwise on a tender form. If your procurement rules require a certified supplier, that rules us out, and it is better established now than at contract stage. What we can offer is a bilateral NDA, isolated repositories and databases per customer, named credential holders, and specific controls written into the contract.

Can an EU company use a development team in Türkiye?

Yes, with the paperwork any non-adequate country requires. Türkiye does not appear on the European Commission's list of adequacy decisions, so transfers of personal data rely on Article 46 safeguards, in practice the Commission's standard contractual clauses together with a transfer impact assessment. Where it fits, the cheaper route is an architecture in which production personal data never leaves your jurisdiction and developers work against anonymised data.

What should I ask a supplier's reference customer?

Not whether they were happy. Ask what changed between the original scope and what was delivered, how the first serious disagreement was resolved, how long support takes to respond now, and whether they could hand the code to another team tomorrow. Those four answers are hard to rehearse.

How do I compare quotes that are wildly different?

Usually the suppliers scoped different systems rather than pricing the same one differently. Send both the identical numbered module list, role list, integration list and record counts, then compare line by line. The remaining gap is a real difference in approach, and worth asking about directly.