DEV Community: Cognivise

Technical discovery: what happens before a software project starts

Cognivise — Mon, 26 Oct 2026 12:16:50 +0000

Discovery is a short phase before development where the supplier works with you to understand the problem, the users and the existing systems, then turns that into a plan. It is not a sales pitch and it is not a build. Its output is clarity: what to build, in what order, how it will work technically, and what it is likely to take.

What discovery covers

The problem and the users. Who needs this, what they do today and what success looks like.
Scope and priorities. What belongs in the first release and what waits.
Existing systems and data. What the new software must connect to, and what state the data is in.
Technical approach. Architecture, hosting, security and third-party services.
Risks. What could delay or derail the project, and how to reduce it.
Plan and estimate. An order of work and a range based on what was learned.

What you should receive

A written summary of scope and priorities.
A technical outline another team could read.
A list of risks and assumptions.
A delivery plan with milestones.
An estimate you can compare with other suppliers.
In some cases, designs or a clickable prototype.

These belong to you. If a supplier will not hand them over without committing to the build, treat that as a warning.

When it is worth it

Discovery pays off when requirements are unclear or disputed inside the business, when the software has to connect to several existing systems, when you need a business case or budget approval, or when the cost of getting it wrong is high. A small, well-understood change may not need it; a short planning conversation can be enough.

Who should be in the room

Someone who can make decisions and say no, because scope needs a decision-maker.
The people who use the current process every day, because they know where it really hurts.
Whoever looks after the existing systems and data.
Finance and security or data protection, when the software handles money or personal data.

What to prepare

You do not need a finished brief. A short pack saves days: a plain description of the problem and who it affects, examples of the documents, screens or spreadsheets used today, a list of the systems the software may connect to with access arranged, and any deadlines, budget limits or rules that cannot move.

What the work looks like

It usually combines conversations with users, a review of the existing systems and data, and working sessions to settle scope and priorities. Some discoveries include a clickable prototype, so people can react to something real rather than a document. Many run for a few weeks, but a supplier should give you a defined scope, timeline and price for the discovery itself before you start.

Warning signs

A fixed price for the whole build after one meeting.
No questions about your users or data.
Deliverables that exist only inside the supplier's tools.
Nobody willing to say what should be left out.

The honest outcome of discovery is sometimes "do not build this yet", or "a simpler option solves it". That result is worth paying for.

The full guide is on the Cognivise blog. To talk about planning a project, see planning and technical advice.

Software project risks: how to spot them early

Cognivise — Mon, 26 Oct 2026 12:16:06 +0000

Most software projects do not fail suddenly. They drift, and the signs show weeks before the missed date. The earliest signals are about information: unclear decisions, no working software to look at, and bad news that arrives late.

Why projects go wrong

Software is hard to see. A building under construction shows its progress to anyone who walks past; a half-built system looks the same from the outside as a finished one. That makes it easy for problems to stay hidden until a deadline arrives.

Nearly all the causes are ordinary: a misunderstood requirement, a decision that nobody made, an integration that behaved differently from its documentation, or a team stretched too thin. All of them show up earlier than people expect if you know where to look.

Early warning signs

You cannot see working software. If the only evidence of progress is a status report, you are relying on opinion. Ask for a demonstration every one to two weeks and try the thing yourself rather than watching someone else click through it.
Decisions are waiting and nobody owns them. If the same question appears in two consecutive updates, it has no owner. Name one person on your side who can decide, and agree how quickly they will.
Scope keeps growing without a conversation. New requests are normal. What matters is whether each one is discussed, priced and traded against something else. Silent growth is how a project ends up late and over budget with nobody having chosen either.
Bad news arrives late or not at all. If every update is green until the week before delivery, the reporting is not showing you the real state. Ask directly: "What is the thing most likely to make us late?"
The same bugs keep returning. Repeated defects often point to something structural, such as missing tests, rushed releases or unclear requirements.
Key people keep changing. Handovers lose knowledge. If the people you met at the start are not the people doing the work, ask who they are, how they were briefed and what has been written down.
Estimates become vague. "Nearly done" and "a few more days" are not estimates. Ask what remains, in a list, and how much of the list is certain.

What you can do about it

Agree what "done" means for each piece of work. A feature that works on the developer's machine but has not been tested is not done.
Keep the first release small. A smaller scope has fewer places to go wrong, and you learn from real use sooner.
Test the riskiest part first. If one integration or one idea could sink the project, tackle it in the first weeks, not the last.
Keep a short risk list. The five things most likely to hurt, who is watching each one and what would trigger action. Review it in every meeting.
Write decisions down. A one-line note of what was decided, by whom and when removes a surprising number of disputes.
Check ownership. Make sure the code and accounts are in your name from the start, so you always have an option if the relationship ends.

If a project is already in trouble

Do not wait for the next milestone to confirm it.

Ask for a clear status: what is finished and demonstrable, what is in progress and what has not started.
Check what remains against the time and money left. If they do not fit, say so now.
Agree a smaller target. Often the right move is to cut scope to something that can be finished well, rather than push everything to the end.
Get an independent view if trust has gone. A short technical audit gives you evidence about the state of the work without changing it.
Keep records. Written requests and replies matter if there is later a disagreement about what was agreed.

A delay alone is not a sign of trouble. What matters is whether you heard about it early, understand the cause and have a realistic new plan.

The full guide is on the Cognivise blog. If you want an independent view of a project, planning and technical advice is where we start.

What a fair software maintenance contract includes

Cognivise — Mon, 26 Oct 2026 12:15:19 +0000

A good software maintenance contract says what is covered, how fast problems are handled and how issues are reported. Fixing bugs, updating dependencies and applying security patches are different from building new features, so check which of them are included.

What it should cover

At minimum, it should state which systems are covered, what kinds of work are included and how you ask for help.

Bug fixes. Correcting behaviour that does not match what was built. Check whether there is a limit on hours.
Security updates. Patching software and libraries as problems are found.
Dependency and platform updates. Keeping the software working as the tools beneath it change.
Monitoring. Watching for outages and errors. Ask whether alerts reach a person.
New features. Usually separate. Ask how changes are requested and priced.

Vague wording such as "reasonable support" causes disputes. Ask for plain descriptions and examples.

How fast problems should be handled

Look for response and resolution targets by severity. A site outage and a spelling error should not have the same priority. Ask for a table with four severity levels and have every target filled in before you sign:

Level	Example	Targets
Critical	The service is down for everyone	First response and target to resolve, agreed in writing
High	A main feature fails for some users	First response and target to resolve, agreed in writing
Normal	A bug with a workaround	First response and target to resolve, agreed in writing
Low	A cosmetic fault	First response and target to resolve, agreed in writing

The targets depend on how much your business relies on the software, so no figures are suggested here. The point is that no target is left blank, and that "resolve" is defined: a fix released, or a workaround in place.

Three pricing shapes

Fixed monthly retainer. The same amount each month for a stated scope. Predictable, and suits software that needs steady monitoring and regular updates.
Block of hours. You buy a number of hours and draw them down. It suits software that changes rarely, but check what happens to unused hours.
Pay as you go. Billed as the work happens. The cheapest when little goes wrong and the most uncertain when something does.

Whichever you choose, ask what is outside the price. Out-of-hours emergency work, major version upgrades and anything that counts as a new feature are the usual exclusions.

Backups and security: four plain questions

Are backups taken, and how often?
Has a restore from backup ever been tested? A backup that has never been restored is an assumption.
Who is told when a security fix is released, and how soon is it applied?
Where is your data stored, and who can access it? If it includes personal data, UK GDPR applies to the supplier as well as to you.

What you should be able to see

A record of work done and time spent, reports on incidents and their causes, and a list of known issues and planned updates. If you cannot see what is being done, you cannot judge whether the contract is worth renewing.

Who owns what

You should have access to the code repository, hosting accounts, domains and documentation at all times, not only while the contract runs. A contract that keeps these under the supplier's control makes leaving difficult.

Check before signing

Which systems and environments are covered?
What are the response and resolution targets?
How are changes requested and priced?
How long is the term, and how do you end it?
What handover do you get if you leave?
Who is accountable when something fails?

If a supplier is reluctant to explain any of these in writing, treat that as information.

The full guide is on the Cognivise blog. For how we handle support after launch, see ongoing support and ownership.

How to write a software project brief that gets comparable quotes

Cognivise — Mon, 26 Oct 2026 12:02:59 +0000

A software project brief describes the problem, the people affected and what success looks like. It is not a feature list. One page that a stranger can follow beats twenty pages nobody finishes.

Every software quote is a reaction to what the supplier thinks you asked for. A vague brief gets a vague quote, and two suppliers can read the same sentence and price two different projects. That is why quotes for the same job often look so far apart.

Seven headings that cover almost everything

1. The problem. Describe what is slow, risky, expensive or impossible today. Write about the situation, not the solution. "Our team re-types orders from emails into three systems, and mistakes reach customers" is a problem. "We need an order portal" is a solution that may or may not fit.

2. Who it is for. List the groups who will use it or be affected: staff, customers, suppliers, managers. Say roughly how many there are and what each needs to do. External users usually mean more design, security and support work than internal ones.

3. What success looks like. Say how you will know it worked, using something you can observe: fewer manual steps, faster turnaround, fewer errors. Avoid targets you cannot measure or have not measured before.

4. What it must do first. List the few things the first release must do for the project to be worth it. Everything else goes on a "later" list. This is the most useful step for controlling cost.

5. What it connects to. Name the systems it has to work with (accounting, a shop, a CRM, a spreadsheet, a payment provider) and what you know about each. Integrations are often where estimates go wrong, because they depend on systems you do not control.

6. Constraints. Budget range or at least a ceiling, a date that cannot move and why, legal duties such as handling personal data under UK GDPR, technology you must or must not use, and who approves decisions. If you do not know the budget, say so.

7. What is out of scope. State what you are not asking for, for example "no mobile app in the first release" or "no data migration from the old system". It feels unnecessary until a disagreement starts.

What to leave out

Detailed screen designs, unless you already have them.
A specific technology, unless there is a real reason. Ask for a recommendation instead.
Every possible feature. A long list hides the important items.
Confidential material you would not share with an unsuccessful bidder.

Is the brief ready?

Give it to someone who has not been involved and ask them to explain it back. If they cannot say what problem is being solved and for whom, rewrite it. Then check: does it say what you want to be true afterwards and not only what you want built? Would two suppliers price roughly the same project from it? Does it say what is fixed and what is open? Does it say who decides on your side?

If you cannot finish the headings yet, that is normal. You may know the problem but not the solution, and a short discovery stage exists for exactly that.

The full guide, with FAQs, is on the Cognivise blog. If you are planning a build, see custom software development.

Legacy system modernisation: repair, replace or leave alone

Cognivise — Mon, 26 Oct 2026 12:02:11 +0000

Age is not what makes a system legacy. Software written fifteen years ago that is understood, documented and cheap to change is not legacy. Software written three years ago that nobody dares touch is. A working definition: a system is legacy when the cost of changing it is out of proportion to the size of the change. Modernisation is the work of bringing that cost back down, and it is not automatically the same thing as replacing the software.

There are four options, not two

The conversation usually collapses into "rebuild or do nothing". Two options sit between them, and they are often the right ones.

Leave it alone. The system is stable, the business is not asking it to change, and it is not a security liability. This is a legitimate answer and is under-used. Software that is finished does not need a project.
Maintain and contain. Keep it patched, monitored and secure, and stop adding to it. New work goes elsewhere. It buys years cheaply and is the right first move when the case for a rebuild is not yet proven.
Modernise in place. Replace parts of it while it keeps running: one module, one integration, one screen at a time. Slower per unit of work, but the business never stops and each step is reversible.
Rebuild. Start again with the same business need and a new implementation. The most expensive and riskiest option, and occasionally the only honest answer, usually when the platform itself is finished rather than merely dated.

Which one fits

Ask what the system is costing you, not how old it is.

Maintain and contain fits when the system does its job, changes are rare, and the complaints are about appearance rather than function.
Modernise in place fits when specific parts generate most of the pain. If four fifths of your change requests touch one module, you have located the problem and it is not the whole application.
Rebuild fits when the platform underneath is genuinely at its end (a runtime with no security updates, a vendor that has gone, a database that can no longer be licensed) or when the business the software models has changed so completely that the data model is wrong rather than just old.

A system that is expensive to change everywhere, with no concentration of pain, usually has a documentation and knowledge problem rather than a technical one. That is cheaper to fix than either modernising or rebuilding, so rule it out first.

Why rebuilding is the wrong default

The new version exists only as an idea, and ideas have no edge cases. The system being replaced has years of them, most undocumented and many load-bearing. A rebuild also delivers nothing until it delivers everything, so the business runs two systems and funds two teams while the old one is frozen. And rebuilds re-learn expensive lessons: the strange rule in the pricing logic is usually there because of something that happened, and the person who remembers may have left.

None of this makes rebuilding wrong. It makes it the option that has to be argued for, not the one everyone assumes.

Modernising in place

The new system goes in front of the old one and takes over functionality a piece at a time. Traffic is routed to whichever implementation owns each piece, and the old system shrinks as the new one grows. Every step is small, releasable and reversible. The cost is real: for a period you run two systems and the routing between them. It is the price of not stopping the business, and it can often be funded from ordinary development budget alongside feature work.

What waiting costs

Deferring is itself a decision. Change gets slower every year, recruitment gets harder, security exposure compounds as unsupported dependencies keep gaining known vulnerabilities, and knowledge keeps leaving with the people who hold it.

The full article is on the Cognivise blog. If you are deciding what to do with an ageing system, planning and technical advice starts with an honest look at its current state.

In-house, agency or dedicated team: how to decide who builds your software

Cognivise — Mon, 26 Oct 2026 12:01:01 +0000

There are three common ways to get software built: hire developers in-house, use an agency for a defined project, or work with a dedicated team. The right one depends on how long the work will last, how fast you need to start and how much control of priorities you want.

The three options

In-house developers. Employees on your payroll, working inside your company.
Agency or project supplier. An outside company that delivers a defined piece of work for an agreed scope.
Dedicated team. An outside team that works only for you, on your priorities, as an extension of your own.

When each makes sense

In-house fits when the software is central to your business and the work will continue for years. You get full control, deep product knowledge and no dependence on a supplier. The costs are time and risk: recruiting takes months, a bad hire is expensive, and you need enough work and management to keep people productive.

An agency fits when the project has a clear scope and an end date, such as a new website, a one-off integration or a first version. You buy a result, and the supplier manages the people. The trade-off is that product knowledge sits partly outside your company, and changing direction mid-project usually means renegotiating scope.

A dedicated team fits ongoing work where you want control of priorities but cannot wait to hire, or where demand will rise and fall. You direct the work day to day while the supplier handles recruitment, employment and replacement.

	In-house	Agency	Dedicated team
Control of priorities	Full	Through the agreed scope	High
Time to start	Slowest	Fast	Fast
Best for	Long-term core product	Defined project	Ongoing work, uneven demand
Main risk	Hiring and retention	Scope disputes	Needs clear direction from you

What each one charges for

Figures vary too much by role, seniority and location to quote, but the shape is useful for comparing quotes. In-house means salary plus employer costs, recruitment, equipment and management time, whether or not there is enough work. An agency charges for a defined scope or a day or hourly rate, and scope changes usually change the price. A dedicated team charges per person, per month or per day, for as long as you keep the team. Ask every supplier what is excluded from the quote: onboarding time, project management and replacing people who leave are the usual gaps.

Questions that settle it

Will this work last more than a year, or is there an end date?
Do you have someone who can direct engineers every day?
How soon must work start?
How much product knowledge must stay inside the company?
Can you afford the delay and risk of recruiting?

Many companies use a mix: a small in-house core with outside capacity around it. Whichever you choose, check that the code and accounts are yours, that documentation is kept current, that there is a defined way to end or change the arrangement, and that you know who is accountable when something fails.

The full guide is on the Cognivise blog. To see how we set up outside teams, read about dedicated development teams.

What is a technical audit, and when do you need one?

Cognivise — Mon, 26 Oct 2026 11:35:07 +0000

A technical audit is an independent review of how a system is built, hosted, secured and maintained. It ends in a written report, not in changes to the system. Its job is to replace opinion with evidence, so the next decision is made on facts. It answers three questions: what state is the system really in, what is the risk, and what should happen first.

What it covers

Most audits look at the same six areas:

Code and structure. How the software is organised, how easy it is to change safely, and whether tests would catch a mistake.
Hosting and infrastructure. Where it runs, how it is deployed and backed up, and what happens if a server fails.
Security. Access control, how secrets such as passwords and keys are stored, how dependencies are kept up to date, and how personal data is protected.
Performance and reliability. Where it is slow, where it fails and whether anyone would know.
Dependencies and licences. Which third-party libraries and services it relies on, and which are out of date or unsupported.
People and process. Who understands the system, how changes are released and what is written down.

An audit does not have to cover everything. A narrow audit of one worry, such as security or hosting cost, is often more useful than a broad one that skims the surface.

When you need one

Something keeps going wrong and nobody can explain why.
The person who built it has left, and the knowledge lived in one head.
You are about to make a large decision: a rebuild, a replatform, buying a company or raising investment.
Costs are rising without a clear reason.
You inherited the system and need an honest starting point.

If none of these apply and the system is stable, understood and maintained, you probably do not need an audit yet.

What a useful report looks like

A summary a non-technical director can follow in a few minutes.
Findings ranked by business impact, not by how interesting they are to engineers.
The evidence behind each finding, so you can check it.
A clear statement of what was not reviewed, and why.
A suggested order of work, with rough effort ranges rather than false precision.

Be cautious of a report that is mostly a list of tools run and warnings produced. Automated scans are a starting point, not an audit.

Audit, discovery or support?

An audit looks at something that already exists and reports on its condition. A discovery looks at something that does not exist yet and works out what to build. Support keeps a system running day to day.

Getting the most from one

Say what decision it should inform: "should we rebuild?" produces a different report from "is this safe to keep running?". Give access early. Ask for the first three things to fix. And where you can, keep the author separate from the fixer, since a reviewer who will also win the follow-on work has a reason to find more to fix.

The full guide, with FAQs, is on the Cognivise blog. If you are unsure where your system stands, planning and technical advice starts with this kind of review.

Is custom software worth it? When bespoke beats off-the-shelf

Cognivise — Mon, 26 Oct 2026 11:34:17 +0000

Custom software (also called bespoke software) is software written for one business instead of adapted to it. The size does not decide it: a small internal tool for one team is custom software, and so is a platform several departments share. It usually covers web applications, business platforms, internal tools, integrations and APIs.

Custom, configured or off-the-shelf?

The practical difference is who adapts to whom. With a product, your process bends to the software. With custom software, the software is shaped to your process. There is also a middle option that is often overlooked: many platforms can be configured heavily or extended with plugins and integrations, which suits a lot of businesses and costs far less than a build.

	Off-the-shelf	Configured platform	Custom
Fit to your process	You adapt to it	Partly adapts, within limits	Built around it
Time to start	Days	Weeks	Months, usually in stages
Cost shape	Subscription, per user	Subscription plus setup	Build cost, then running cost
Control over changes	Vendor's roadmap	Mostly the vendor's	Yours
Main risk	Workarounds pile up	Hitting the platform's ceiling	Building the wrong thing

When it is worth considering

Workarounds are someone's job. Exports are copied between systems by hand, and the person doing it is one of your most experienced.
Numbers stop agreeing. Two systems hold the same facts and nobody is sure which is right.
The process is how you compete. Forcing it into a generic tool removes the advantage.
Licence costs scale badly. Per-user pricing grows with your team while the value of the tool does not.
Fragile integrations. A failure between tools stops the business.

A good test: if your team spends more time working around the software than using it, you are already paying for custom software. You are just not getting it.

When it is not

It is not worth it when a good product already does the job. Payroll, email, accounting and most standard processes fall in this group. It is also the wrong move when the requirements are still unclear and change every month, when nobody inside the business will own the software after launch, or when the real problem is a process or training issue that software will not fix.

What drives the cost

There is no honest single figure. A realistic estimate depends on scope (workflows, screens, rules), integrations, users and roles, data migration (often the most underestimated part), compliance and security such as UK GDPR, and running costs after launch. Ask for an estimate that lists its assumptions. A number with no assumptions is a guess. Building in stages helps, because you can stop or change direction after each one.

Questions for any supplier

Who owns the code when the project ends, and do you get full access to it?
Are the people you meet the people who build it?
Is progress shown as working software in stages?
What happens after launch, and who fixes problems?
How is your data handled?
What would make them say no? A good company can tell you which projects it would not take.

Start with the problem, not the technology: write down what is going wrong, who it affects and what it costs in time each week.

The full guide is on the Cognivise blog. For how we approach builds, see custom software development.

Dedicated team, contractor or permanent hire? How to choose

Cognivise — Mon, 26 Oct 2026 11:29:48 +0000

There are three ways to add engineering capacity: one or two contractors, a dedicated development team, or a permanent hire. They are not interchangeable. The difference that matters is how long the need lasts and who carries the risk.

What a dedicated team is

A dedicated development team is a group of engineers who work on your project through a supplier rather than on your payroll. They are not shared across other clients, and they normally include the roles a project needs, not only developers: designers, QA and DevOps as well.

The label is not the important part. What matters is that the supplier carries the hiring, the contracts, the replacement risk and the equipment, and you direct the work. If a supplier offers a "dedicated team" but rotates people between clients, it is staff augmentation with a better name.

How they compare

	One or two contractors	Dedicated team	Permanent hire
Best when	A narrow, well-defined skills gap	A plan that will run for quarters, with too few people	The role is indefinite and the knowledge should stay in your company
Speed to start	Fastest	Slower than a contractor, faster than hiring	Slowest: notice periods and recruitment
Hiring and replacement risk	You or an agency	The supplier	You
Easiest to stop	Yes	Within the notice period in the contract	No
Cost shape	Day rate	Per person, per month or per day	Salary plus employer costs

Questions worth asking any supplier

Who exactly is on the team? Names, seniority and what else they are working on. If you cannot find that out before signing, you will not find it out afterwards.
Who owns the code? It should be you, by default, in your own repositories and accounts.
What happens if this does not work? Notice period, how work in progress is handed back, and whether the documentation is part of the work or an extra.
Who do I talk to when something is wrong? An engineer on the team, or an account manager relaying messages.

How to tell it is working

Set this before the team starts, not after the first disagreement. The useful signals are boring ones: work reaching your users at a steady rate, questions that show the team understands the business, and problems surfacing early instead of at the deadline. Agree what "done" means for the first piece of work.

When it is the wrong answer

If you do not yet know what you are building, a team will build the wrong thing efficiently. If the work is short and well-bounded, one specialist is simpler. And if the knowledge needs to stay in the company for years, hire.

The full version, with the step-by-step process, cost points and UK contract checks, is on the Cognivise blog. If you are weighing up a team, how we set up dedicated development teams explains our approach.

MVP development for UK startups: what to build first

Cognivise — Fri, 09 Oct 2026 12:52:34 +0000

Key takeaways

An MVP exists to answer one question, such as whether customers will pay or use it every week, so write that question down before you scope anything.
Build the one path a customer takes from problem to result, and leave out admin tools, settings and edge cases until real use shows you need them.
Decide in advance what result counts as proceed, change or stop, otherwise every outcome reads as encouraging.
Own the code and the accounts from day one, so you can change supplier or hire in-house later.

A minimum viable product (MVP) is the smallest working version of your idea that lets real people use it and tell you whether it is worth building further. It is not a cheap, unfinished copy of the final product. It is an experiment that happens to be made of software.

That difference decides most outcomes. Founders who treat the MVP as version 0.1 of everything end up paying for features nobody has asked for. Founders who treat it as a test usually ship sooner and learn more.

Start with the question the MVP has to answer

Before listing features, write one sentence: "This MVP will tell us whether ___."

Good examples are specific and can be answered by behaviour, not opinion:

Will small clinics pay to book appointments through this instead of the phone?
Will buyers come back a second time without being reminded?
Can we deliver the service with a small team, or does it only work with heavy manual effort?

If you cannot finish the sentence, the project is not ready to be scoped. A short planning session is cheaper than a build that tests nothing.

Build one path, not a small version of everything

Pick the single route a customer takes from having the problem to getting the result. Build that, end to end, and make it work properly.

Usually left out of a first version:

admin dashboards, when you can edit data directly for the first few customers
user roles and permissions beyond the ones you need today
reporting and analytics beyond the one measure that answers your question
integrations with systems your first customers do not use
settings, themes and customisation

Some of these will come back. The point is that real use, not guesswork, tells you which ones.

Manual work behind the scenes is acceptable in an MVP. If a person can handle an invoice by hand for the first twenty customers, you do not need to automate it yet.

What can stay unfinished, and what cannot

Cutting scope does not mean cutting everything. Some things are expensive to fix later, so they belong in the first version:

Data protection. If you collect personal data from UK users, UK GDPR applies from the first customer. The ICO's guidance for small organisations is the place to start.
Security basics. Sensible authentication, encrypted connections and access limited to what each person needs.
Payments. Use an established payment provider rather than handling card details yourself.
A sound data model. Screens are easy to change. The shape of the data underneath is much harder to change once customers rely on it.

If your product touches a regulated area such as finance, health or children's data, take advice before you build, not after.

Choose the build route that fits the question

There are four common routes, and none is right for every startup.

Route	Suits	Watch for
No-code or off-the-shelf tools	Testing demand with very little custom logic	Hitting limits as soon as the idea works
Freelancer or small agency	A clear, small scope	Single points of failure and thin documentation
Software partner	A product that needs design, engineering and planning together	Choose on how they scope, not on the quote
In-house hire	A long-term product with funding behind it	Time to hire before anything ships

Whichever you pick, the questions in our guide on how to choose a software development company apply. Ask who owns the code, who holds the hosting and domain accounts, and what you receive if the relationship ends.

Be honest about cost and time

An MVP does not have a standard price. It depends on the number of user types, how many systems it connects to, and how much has to be designed rather than copied from existing patterns. Our guide to what drives the cost of custom software explains those drivers.

A better question than "what does an MVP cost?" is "what is the cheapest build that answers our question?" A supplier who scopes against that question is more useful than one who quotes against a feature list.

Short delivery cycles help. You should see working software every couple of weeks, not at the end.

Decide what success looks like before launch

Write down three outcomes before the first user arrives:

Proceed: the result that makes you invest further.
Change: the result that tells you the idea is right but the approach is wrong.
Stop: the result that tells you to put the money elsewhere.

Without this, every number looks like progress. Ten sign-ups is a strong result for one product and a failure for another. Choose the thresholds while you are still calm.

Keep ownership clear

Whoever builds it, check these from the start:

the code sits in a repository you control
the hosting, domain and third-party accounts are in your company's name
the documentation is enough for another developer to pick it up
the contract says the intellectual property is yours

These cost nothing at the beginning and a great deal to untangle later, especially when investors run due diligence.

What happens after the MVP

If the test works, the next step is rarely "add everything we cut". It is to strengthen what customers actually used, then add what they asked for most. If you later need more engineers, our guide to hiring a dedicated development team covers the options.

If the test does not work, a clean result is still worth having. You learned it for the price of an MVP rather than a full product.

Frequently asked questions

How long does an MVP take to build? It depends on scope. A tightly focused first version often ships in weeks rather than months, and a good supplier will agree the scope against your question before giving a timeline.

Should an MVP be built on no-code tools? Sometimes. They suit testing demand with little custom logic. Plan for the point where the idea works and the tool becomes the constraint.

Do I need a technical co-founder? Not necessarily, but someone on your side needs to understand the decisions being made. A planning engagement or technical adviser can fill that role while you validate the idea.

Who should own the code? You should. Check this in writing before work starts.

If you are weighing a first build, our software development for startups page explains how we scope and deliver, and you can contact us to talk it through.

Related

Originally published on Cognivise.

How to choose a software development company

Cognivise — Fri, 09 Oct 2026 12:50:21 +0000

Start with the question you actually need answered

Before comparing suppliers, be clear about which of three things you need, because they are arranged differently. A defined piece of work with a shape you can describe. Capacity, because you know what to build and have too few people. Or a decision, because you are not yet sure what is worth building at all.

A supplier who is good at one is not automatically good at the others. Asking a delivery-focused firm to tell you what to build, or a consultancy to staff a team, produces a bad fit that neither side notices until the invoices start.

What a shortlist should actually test

A portfolio shows what shipped. It does not show what it cost, how long it took, how much of it was rewritten in the first year, or whether the people who built it still work there. So test the things that do predict the outcome.

Directory rankings are worth less than they look. A list of the top software development companies is usually ordered by who paid, reviewed, or submitted a profile: useful for finding candidates, useless for ranking them. Treat it as a source of names and do your own comparison.

Who specifically will do the work. Not the company's average experience: the named people on your engagement. Ask what else they are on, and what happens if one of them leaves mid-project. If the answer is vague, you are being offered one team and delivered a different one.
Whether they will tell you no. Describe something slightly wrong on purpose, such as a feature that does not fit or a deadline that is not realistic. A supplier who agrees to everything in the sales conversation will agree to everything in delivery too, and that is how scope quietly becomes your problem.
What happens after launch. Ask who maintains it, on what terms, and what it costs. A quote that ends at launch is not a quote for working software. Support is either priced now or negotiated later from a weak position.
Who owns the code. It should be you, in your own accounts, from the start rather than at the end. If ownership transfers only on final payment, or the supplier keeps parts of it as their framework, you are renting.

Software development pricing models, and what each one hides

Most quotes come in one of three shapes. None is dishonest; each moves risk to a different place, and knowing which is the point.

Before comparing them, be wary of anyone who answers "how much does custom software cost" with a number before asking what it has to do. Custom software development cost is a function of scope, integration and how much is still unknown, and a figure quoted without those is a sales tactic rather than an estimate.

Fixed price. You pay an agreed amount for an agreed scope. The supplier carries the risk of it taking longer, and prices that risk into the number. Works when the scope genuinely can be held still. When it cannot, every discovery becomes a change request and the relationship turns adversarial.
Time and materials. You pay for the hours worked. You carry the overrun risk, and in exchange you can change direction without renegotiating. Fixed price vs time and materials is really a question about how well you can specify the work, not about which is cheaper.
A capped or staged budget. Time and materials with a ceiling, or a series of small fixed pieces. Usually the most honest arrangement for work that is partly unknown, because it keeps both the flexibility and a number you can plan around.

What the software development contract has to say

The contract matters most in the situations nobody expects when signing it. Four clauses do the work.

Ownership of the source code, the documentation and the accounts, stated as transferring during the engagement rather than at the end. Test it by asking for repository access on day one.

What happens when scope changes: who decides, how it is priced, and whether work pauses while that is agreed. This is the clause that decides whether a discovery is a conversation or a dispute.

Exit. How much notice, what gets handed over, and in what state. A supplier confident in their work makes leaving easy, because they do not expect you to want to.

Support after launch: response times, what counts as a defect rather than a change, and what it costs. Agree it before launch, when you still have leverage.

Signals that a supplier will be expensive in ways the quote does not show

A quote far below the others is not a bargain. It usually means a different scope was understood, or that the gap will be recovered through change requests. Ask what they assumed, and compare assumptions rather than totals.

A proposal that arrives immediately, without questions, describes a generic project rather than yours. Good software development proposals are slower because they involve someone actually thinking about your situation.

Being unable to name a project that went badly. Everyone has one. A supplier who cannot describe what went wrong and what they changed has either not been doing it long or is not being straight with you.

Talking only about technology. The stack matters far less than whether they understood the business problem, and a conversation that never leaves the tooling is usually hiding that they did not.

Questions worth asking every supplier

What would you need from us to make this work? Every engagement depends on the client for something: decisions, access, a person who can answer questions. A supplier who says they need nothing has not thought about it, and you will find out which things they needed when they are late.

What is the first thing you would build? The answer shows whether they think in terms of risk or in terms of features. The first thing should usually be the part you are least certain about.

How will we know it is going badly? Ask for the specific signal and when you would see it. "Weekly demos" is an answer. "Good communication" is not.

What would make you turn this down? It tests whether they have a view at all. A supplier with no conditions will take anything, which tells you what their judgement is worth on your project.

When the answer is not to hire a company at all

Sometimes the honest recommendation is an off-the-shelf product with some configuration, and a good supplier will say so. Custom software earns its cost when the process is genuinely yours, when the integration is the point, or when the thing you need does not exist. Not when an existing tool almost fits and nobody has tried it properly.

And if the need is continuous rather than a project, hiring your own engineers is usually cheaper over a few years than any supplier, whatever the day rate comparison says. The reason to use a company is speed, specific expertise, or not wanting to carry the hiring risk, all legitimate, and all worth being explicit about.

Related

Originally published on Cognivise.

Ecommerce SEO checklist for a UK online shop

Cognivise — Fri, 09 Oct 2026 12:47:00 +0000

Key takeaways

Give every product and category one clean, readable URL, and link to it the same way everywhere.
Decide in advance which filter, sort and pagination URLs should be indexed, because shops generate thousands of near-duplicates.
Keep products with temporary stock gaps live and say so; send discontinued ones somewhere relevant or let them return a real 404.
Write product pages that add something the supplier's copy does not, and keep prices and stock in structured data identical to what shoppers see.
Fix structure first, then content, then extras such as reviews and rich results.

What is ecommerce SEO?

Ecommerce SEO is making the pages of an online shop easy for search engines to find and understand, and useful enough to deserve to rank. It differs from SEO for a small site because a shop produces pages in bulk: every product, category, filter combination, sort order and variant can become its own URL.

That is why most shop problems are structural. A site with 500 products can easily expose tens of thousands of URLs, and a search engine has to work out which ones matter. This checklist is ordered by how much trouble each area tends to cause.

How should product and category URLs look?

Short, readable and consistent. A person should be able to guess roughly what a page is from its address.

Use descriptive words, not internal IDs. Prefer /products/black-leather-wallet to /products/3243.
Use one letter case everywhere, normally lowercase, so the same page is never reachable under two spellings.
Never change page content with a # fragment. Google ignores everything after it, so #black and #white are the same page to a crawler.
Keep session IDs, tracking codes and values such as time=last-week out of internal links, because they create short-lived duplicates.
Write parameters as ?key=value, not ?value, and join multiple values with a comma, for example ?type=candy,sweet.
Link to the same URL everywhere: in menus, in the sitemap and in the canonical tag. If these disagree, you are asking Google to guess.

How should you structure categories and internal links?

Search engines work out how your shop is organised mainly from links, not from URL patterns. Every important page should be reachable by following ordinary links from the home page through categories to products.

Build a clear hierarchy: home, category, subcategory, product.
Show a visible breadcrumb trail and mark it up with BreadcrumbList, so the hierarchy is stated in two ways.
Link to your most important products and categories from the home page and from relevant content. The more internal links a page has, the more important it looks.
Do not rely on your search box to expose products. Crawlers do not type into it.
Add real text to category pages, such as a short introduction and advice on choosing, because a bare grid of products gives little to rank on.

How do you handle filters, sorting and pagination?

This is where shops lose the most crawl effort. Decide the rules up front.

Give each page of a category its own URL, for example ?page=2.
Give each page in the sequence its own canonical URL. Do not point every page at page one.
Link pages to each other with normal links. A "load more" button or infinite scroll that needs a click or scroll to reveal products is invisible to crawlers unless there are paginated URLs behind it.
Stop sort orders and most filter combinations from being indexed. Google suggests noindex or robots rules for variations such as ?order=price.
Allow the occasional filtered page to be indexed only when people actually search for it, such as a brand within a category, and give it a proper title and some text of its own.
Do not worry that pages in a sequence share a similar title. Google says that is acceptable.
Do not bother with rel="next" and rel="prev". Google no longer uses them.

What should you do about product variants?

Variants such as size and colour are the second big source of duplicates.

Choose one approach. Either give each variant its own URL, as a path (/t-shirt/green) or a parameter (/t-shirt?color=green), or keep all variants on one page.
If variants have separate URLs, use the version without the parameter as the canonical.
Group variants in structured data with ProductGroup, so Google understands they are one product in several versions.
Give every variant its own identifier, such as a SKU.

What should happen to out-of-stock and discontinued products?

Google's ecommerce documents do not give a single rule for this, so what follows is practical advice rather than an official procedure.

Temporarily out of stock: keep the page live, say clearly that it is unavailable and when it is expected back, and mark availability correctly in structured data. A product page that keeps its history is worth more than a new one.
Permanently discontinued with a close replacement: redirect with a 301 to the replacement.
Permanently discontinued with no replacement: return a proper 404 or 410. Do not redirect everything to the home page, because that is treated as a soft error.
Do not use the URL removal tool to hide products that are only out of stock. It is a temporary measure.
Empty categories: either add noindex or return a 404 until products return.

What makes a good product page?

A page that tells a buyer what they need to know and says it in your own words.

Write your own description. Copying the manufacturer's text means you are one of dozens of identical pages.
Include the details buyers ask about: sizes, materials, compatibility, what is in the box.
Use sharp images, placed near the text that describes them, with short, accurate alt text.
Show delivery costs and times, and your returns policy, where a UK shopper would look before buying.
Publish only genuine reviews. Never mark up reviews that are not visible on the page, and never invent them.
Mark up the product with Product structured data: name, image, price, currency (GBP for a UK shop) and availability. The values must match what is on the page.

Structured data does not make a weak page rank. Its job is to state clearly what a good page already shows.

If you also want products to appear in Google's shopping results, you can send them through Merchant Center. Check its policies for your product category first, because some categories of goods are restricted.

What technical basics should you check?

Product and category content is in the HTML, not added only after scripts run.
Navigation uses real links, not click handlers alone.
Robots.txt does not block the CSS, JavaScript or images needed to display pages.
Core Web Vitals are in the "good" range: LCP within 2.5 seconds, INP under 200 milliseconds, CLS under 0.1.
The whole site runs on HTTPS, with one preferred hostname and permanent redirects from the others.
An XML sitemap lists the pages you want indexed and nothing else.
The mobile page has the same content as the desktop page, since Google indexes the mobile version.

Where should you start?

Work in this order, because each step makes the next one easier:

Fix URLs, duplicates and the filter and pagination rules.
Check the category structure and internal links.
Handle stock and discontinued products properly.
Improve the product and category pages that already get visits.
Add structured data, then reviews and extras.

A good test before you begin: pick one category and count how many different URLs show its products. If the number surprises you, start there. If you would like a second pair of eyes on that, our ecommerce SEO services begin with exactly this kind of review. If you are planning a new shop, these decisions are far cheaper to make before the store is built.

Related

Originally published on Cognivise.