DEV Community: Masoud Gorgani

MVP development for UK startups: what to build first

Masoud Gorgani — 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

Masoud Gorgani — 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

Masoud Gorgani — 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.

What is GEO? A plain guide to AI search

Masoud Gorgani — Fri, 09 Oct 2026 11:09:04 +0000

Key takeaways

GEO means making your content easy for AI answer tools to find, understand and cite.
Google says optimising for its AI features is the same work as SEO, with no extra markup or files required.
The basics decide eligibility: pages must be crawlable, indexed and allowed to show a snippet.
Be wary of anything sold as a secret: llms.txt, content chopped into fragments and tools claiming inside data have no support from Google.
Measure with Search Console, your own analytics and a fixed list of real questions, and expect variation.

What is GEO?

GEO, short for generative engine optimisation, is the practice of making your content easy for AI answer tools to find, understand and cite. Those tools include Google's AI Overviews and AI Mode, and assistants such as ChatGPT and Perplexity. Instead of a list of ten links, the reader gets a written answer, sometimes with links to the pages it drew on.

You will also see AEO, answer engine optimisation. In practice the two terms describe the same thing, and neither is a standard with an official definition.

One warning about wording. "AI optimisation" is used for two different jobs. One is optimising your site for AI answers, which this article covers. The other is using AI to improve how a business runs, such as automating a process or building an assistant. That second job is AI development, and it has nothing to do with search.

How is GEO different from SEO?

For Google, it largely is not. Google's own guidance says its AI features rely on the same core ranking systems as normal search, and that you do not need special optimisation or extra technical requirements to appear in them.

What changes is how results are presented and measured, not what makes a page good.

	SEO	GEO
Goal	Rank in search results	Be cited in AI answers
What the reader sees	A list of links	A written answer, often with a few links
Success measure	Rankings, clicks	Mentions, citations, referral traffic
Foundations	Crawlable, useful, well-linked pages	The same, plus clear, quotable answers
Evidence	Mature and well documented	Thin outside Google's own statements

The last row matters. Google publishes what it expects. Most other assistants publish far less, so claims about exactly how they pick sources are usually educated guesses.

How do AI answers choose their sources?

Google describes two techniques. The first, retrieval-augmented generation, means the system finds relevant pages in the search index and uses them to ground its answer. The second, query fan-out, means it runs several related searches across subtopics to gather more material.

Put simply, an AI answer is built from pages the system can already find. That is why the starting requirements are ordinary ones. For Google's AI features, a page needs to be indexed and eligible to appear in search with a snippet. Google states there are no additional technical requirements. Meeting them still does not guarantee you will be shown.

What actually helps?

Most of what helps is what already helps in search:

Be findable. Pages must be crawlable and indexable, and important content should be in the HTML, not hidden behind scripts that only run later.
Answer the question early. Put the answer in the first two sentences of a section, then explain. People and machines both quote clear answers.
Say something original. Content that repeats what ten other pages say gives a system no reason to pick yours. A real point of view, your own data or first-hand experience does.
Show who is behind it. Name the company, say what it does, and make contact details and authorship easy to find.
Keep facts consistent. Your name, services and claims should agree across your site and your public profiles.
Look after page experience. A fast, readable page on every device is still part of the picture.
Keep structured data accurate. It is not required for AI features, but it is still worth having where it matches what is on the page.

If a page would be a poor answer for a person who found it in a normal search, it will not become a good source because you added the word "AI" to it.

What is a waste of time?

Google is direct about several tactics, and they are worth avoiding:

llms.txt files and other special AI markup. Google says Search ignores them. Publishing one does no harm for other tools, but do not expect it to change anything in Google.
Cutting content into tiny pieces for machines. Google says there is no requirement to do this.
A separate page for every possible variation of a question. At scale this risks being treated as spam.
Buying or faking mentions around the web. Inauthentic mentions are not a shortcut.
Tools that claim to show Google's internal ranking or AI data. Google says no third-party tool has access to it.

If someone promises guaranteed placement in AI answers, treat that as a warning sign, for the same reason you would with guaranteed rankings.

How can you measure it?

There is no perfect measure, so combine three imperfect ones.

Search Console. Google says traffic from its AI features is counted within the Web search type in the Performance report, so you cannot split it out cleanly.
Your own analytics. Look for visits referred from AI assistants and watch whether they behave differently from search visitors.
A fixed list of real questions. Pick 10 to 20 questions customers actually ask, check them on a regular schedule, and record whether you are cited. Answers vary between runs, so look for a trend, not a single result.

Should you block AI crawlers?

That depends on what you want. Some bots collect content to train models. Others fetch pages in order to answer a user's question and link back. Blocking the first group does not remove you from Google Search or its AI features. Blocking the second can mean those assistants cannot cite you.

Check your robots.txt matches your decision. If you want to limit how much of a page Google can show, the existing controls such as nosnippet and max-snippet apply, but they also reduce how your content can appear in search.

Where should you start?

Start with a short list rather than a programme:

Check your important pages are crawlable and indexed.
Rewrite your key pages so each opens with a clear answer to the question it targets.
Add the company details and authorship a stranger would look for.
Decide your AI crawler policy and make robots.txt match it.
Set up the question list and check it monthly.

That is the core of our SEO and GEO services. If you run an online shop, the same steps apply to product and category pages, covered in ecommerce SEO.

Related

Originally published on Cognivise.

How Much Does Custom Software Cost? What Actually Drives the Price

Masoud Gorgani — Fri, 09 Oct 2026 11:07:22 +0000

This guide covers those factors, the common pricing models, and how to get quotes you can compare fairly.

The short answer

Cost follows scope: how many features, users, and connected systems.
Most of the cost is people's time, not licences or hardware.
A clear brief before work starts is the cheapest way to lower the final bill.
Any firm that quotes a number without asking questions is guessing.

What drives the cost of custom software?

1. Scope and number of features

Every feature has to be designed, built, tested and maintained. A tool that does one job well costs less than one that does ten. Splitting the work into a first release and later releases is the most reliable way to control cost.

2. Number and type of users

A tool for five staff is simpler than one used by customers or suppliers. External users usually mean accounts, permissions, security checks and support, all of which add work.

3. Integrations with other systems

Connecting to your accounting package, shop, CRM or warehouse system takes time. Each integration depends on how good the other system's documentation and interface are. Poorly documented or old systems cost more to connect.

4. Design and user experience

A screen only your own team sees can be plain. A product customers use needs more design, testing and polish. Be clear about who the users are and what "good enough" means.

5. Data migration

Moving data out of spreadsheets or an old system is often underestimated. Messy, duplicated or inconsistent data has to be cleaned before it can be trusted.

6. Security, compliance and reliability

Handling personal, payment or health data adds requirements for security, access control and record keeping. Software that must stay online all day needs more testing and monitoring than one used once a week.

7. Who builds it, and how they work

Team size, seniority and how closely they work with you all affect the price. A cheaper day rate does not always mean a cheaper project. Rework caused by unclear requirements costs more than good planning.

How do software pricing models differ?

Fixed price

You agree a price for a defined scope. This suits small, well-understood projects. The risk is that any change to the scope becomes a separate negotiation.

Time and materials

You pay for the time spent, usually with a budget cap and regular reporting. This suits projects where requirements will change as you learn. It needs good visibility so you can see progress against spend.

Dedicated team

A team works only on your product for an agreed period. This suits long-running products with steady work.

None is always better. The right choice depends on how well you can define the work today.

Why is the first conversation so important?

Cost becomes predictable once the problem is clear. A short discovery stage turns "we need a system" into a written scope, a list of priorities and a plan for a first release. It is where most wasted spend is avoided. See technical discovery explained.

How to get quotes you can compare

Write down the problem, not the solution. Describe what is slow, risky or manual today.
List who will use it and which systems it must connect to.
Say what must be in the first release and what can wait.
Ask each supplier what is and is not included, including testing, hosting, documentation and support after launch.
Ask how changes are handled once work has started.
Ask who will actually do the work and how often you will see progress.

If two quotes differ a lot, the scope behind them probably differs too. Ask each to explain their assumptions.

Is custom software worth it?

It depends on whether off-the-shelf tools already fit. If a standard product does the job, buying is usually quicker. Custom software makes sense when your process is a real advantage, when workarounds are costing time every week, or when you have outgrown your tools. Our guide to custom software development in the UK walks through the decision.

FAQs

Can I get a fixed price for custom software?

Yes, for a well-defined scope. If the requirements are still changing, a time-and-materials model with a budget cap is often safer for both sides.

Why do two quotes for the same project differ so much?

Usually the scope, assumptions or team differ. One quote may leave out testing, data migration, or support after launch. Compare what is included, not just the total.

Are there ongoing costs after launch?

Yes. Plan for hosting, monitoring, security updates and small improvements. Ask every supplier to explain what they include after go-live.

Does a smaller first version really save money?

Often, yes. A first release covering the most important jobs lets you test the idea with real users before committing to the full list of features.

How do I know I am not overpaying?

Ask for a written scope, a breakdown of the work, and clear assumptions. A supplier who explains their reasoning and asks you detailed questions is easier to trust than one who gives a single figure on the first call.

Talk to us about your project

Not sure what your project would involve? Discuss your project with Cognivise and we will help you shape a clear scope you can price with confidence.

Originally published on Cognivise.

Shopify or a custom store: how to choose a platform

Masoud Gorgani — Fri, 09 Oct 2026 11:04:45 +0000

Key takeaways

A hosted platform such as Shopify handles checkout, payments and orders, and suits most shops whose process is fairly standard.
A custom or headless storefront is worth it when you need control over experience, performance or integrations the platform cannot give you.
Decide on what you must control, then count the cost of maintaining it, not just the build.
Whichever you choose, plan URLs, product data and search visibility before you start.

Do you need a custom store at all?

Often not. A hosted platform gives you checkout, payments, order management and security updates that someone else maintains. If your products and process are fairly standard, building those yourself rarely pays for itself.

A custom approach earns its place only when the platform stops you doing something your business depends on.

What are the main options?

Option	What it means
Hosted platform, standard theme	Fastest and cheapest to start. Fits shops with a conventional catalogue and checkout.
Hosted platform, customised theme or apps	Covers most extra needs with less risk. Watch the number of apps, which add cost and slow the site.
Headless or custom storefront on a platform	The platform keeps handling products, orders and checkout while you build the front end yourself. More control, more to maintain.
Fully custom build	Suits unusual business models. Highest cost and ongoing responsibility, including security and payments.

When is a hosted platform the right answer?

you sell physical products with ordinary variants and delivery options
your team wants to update products and content without a developer
you want payments, tax and security handled for you
speed to launch matters more than a unique experience

When is a custom or headless storefront worth it?

the buying experience is central to what you sell, for example complex configuration
you need performance or design control a theme cannot deliver
you connect to systems such as ERP, stock or pricing tools in ways apps cannot
several storefronts share one catalogue

Be honest about the second cost: someone has to maintain it. A custom front end needs developers available after launch, and bugs become your responsibility. See what support and maintenance cover.

What should you decide before choosing?

What must your team control that the platform does not allow?
Who will update content, and who will fix problems?
What systems does the store need to connect to?
What does your search traffic depend on, and how will URLs be kept?
What happens to your data if you leave the platform?

What about search visibility?

Any platform change can lose rankings if URLs, titles and structured content are not carried across. This is a planning issue, not a platform issue. Our ecommerce SEO checklist covers what to check.

Frequently asked questions

Is Shopify good for SEO? It gives you the basics, and results depend on how you structure products, collections and content. No platform ranks a store on its own.

Can we start on a platform and go custom later? Yes, and it is often sensible. Keep your product data clean and your URLs stable so a later move is easier.

Who owns the store? You should own the accounts, domain and any custom code. Confirm this in writing.

If you are choosing a platform or planning a rebuild, see our website and online store development page or contact us.

Related

Originally published on Cognivise.

Staff augmentation vs outsourcing, managed services and consulting

Masoud Gorgani — Wed, 30 Sep 2026 15:16:36 +0000

These four arrangements get quoted against each other as though they were competing prices for the same thing. They are not. They differ in who directs the work and who carries the risk, and those two questions decide which one fits.

What is staff augmentation, and what are the alternatives?

Most of the confusion comes from suppliers using whichever term sounds best, so it is worth being plain about what each one means before comparing them. The benefits of staff augmentation and of the other three are not in dispute; which benefit you need is the whole question.

Staff augmentation — You hire people, not an outcome. Engineers join your team, work to your priorities, use your tools and report to your managers. The supplier handles employment, payroll and replacement. Also called team augmentation, resource augmentation or IT staffing.
Outsourcing a project — You pay for an outcome, not people. The supplier takes a defined scope, staffs it themselves, and is accountable for delivering it. You review the result rather than directing the work day to day.
Managed services — You pay for an ongoing service level rather than either. The supplier runs and maintains something — an application, a platform, a support desk — against agreed response times, and decides for themselves how many people that takes.
Consulting — You pay for judgement. Someone assesses a situation and tells you what to do about it. Some consultancies then offer to do it; the advice and the delivery are separate engagements, and it is worth knowing which one you are being offered.

The difference that actually decides it

Strip away the labels and two questions separate these arrangements. Who directs the work, and who carries the risk if it goes wrong.

With staff augmentation you direct the work and you carry the delivery risk. The supplier guarantees that a competent person turns up; they do not guarantee that the thing gets built, because they are not deciding what gets built. If the roadmap is wrong, that is yours.

With outsourcing the supplier takes both. They decide how to staff and sequence the work, and they are on the hook for the result. That is why outsourcing contracts have detailed scopes: the scope is the thing being guaranteed, so both sides need it written down.

Neither is safer than the other. They put the risk in different places, and the right answer depends on which risk your company is better equipped to carry.

Staff augmentation vs outsourcing

This is the comparison people ask for most, and the honest answer is that it turns on how well you can specify the work.

If you can write down what needs building in enough detail to hold someone to it, outsourcing transfers real risk and is usually worth it. If you cannot — because the product is still being discovered, or the requirements change monthly — a fixed scope becomes a change-request argument, and staff augmentation avoids that by not pretending the scope is stable.

The second factor is whether you have someone to direct the work. Staff augmentation assumes you do. If nobody on your side has the time or the technical standing to set priorities and make decisions, augmented engineers will wait, and you will pay for the waiting.

Cost usually favours outsourcing on paper and staff augmentation in practice, for the same reason: the outsourced price covers the scope as specified, and most scopes change.

Staff augmentation vs managed services

Managed services are not a third way of building something. They are a way of running something that already exists.

The contract is written around availability and response rather than output — an hour to acknowledge a critical incident, a day to resolve it, a monthly allowance for changes. You stop paying for people and start paying for a guarantee.

That is good value when the work is genuinely continuous and unpredictable, which is what application support usually is. It is poor value when the work is a project with an end, because you end up paying an availability premium for capacity you could have hired directly.

Staff augmentation vs consulting

Consulting is the answer when the problem is a decision, not a shortage of hands. What to build, whether to rebuild, which platform, whether the supplier you already have is doing a competent job.

The trap is paying for consulting when you actually needed capacity. A strategy document does not build anything, and a team that already knew what to do does not need one. The reverse trap is just as common: hiring engineers to build something nobody has established is worth building.

A useful test is whether you could brief the work today. If yes, you need capacity. If the honest answer is that you would be guessing, the cheapest step you can take is a few weeks of someone working out what the answer is.

Which one fits your situation

Choose staff augmentation when — You know what to build, you have people who understand the business, and there are not enough of them. You have someone able to direct the work, and the requirements will keep moving.
Choose project outsourcing when — The scope can be written down and held still, you have no one available to manage engineers day to day, and you would rather pay for a delivered result than a team.
Choose managed services when — The software already exists and someone has to keep it running. The work is unpredictable in timing but continuous in nature, and downtime has a cost you can put a number on.
Choose consulting when — You cannot yet brief the work. The decision is the problem — what to build, whether to rebuild, or whether the current approach is sound.

What goes wrong with each

Staff augmentation fails when nobody on the client side is directing the work. Engineers arrive, wait for decisions, and become expensive. It also fails when a supplier rotates people between clients and calls it a dedicated team: you pay the onboarding cost repeatedly and never accumulate anyone who knows your system.

Outsourcing fails when the scope was a guess. Every discovered requirement becomes a commercial negotiation, the relationship turns adversarial, and both sides start optimising for the contract rather than the software.

Managed services fail when the service level was written for a different kind of software than the one you have. A four-hour response is meaningless if the failure mode is silent data corruption nobody notices for a week.

Consulting fails when the advice is not accountable to delivery. Recommendations from people who will not have to live with them tend towards the ambitious.

You can combine them, and most companies do

These are not exclusive. A common and sensible sequence is a short piece of consulting to decide what to build, a dedicated team or augmented engineers to build it, and a support arrangement once it is live.

What matters is being clear which one you are paying for at any given moment, because the thing being guaranteed is different in each. Confusion about that is the single most common reason these arrangements disappoint.

Originally published on the Cognivise blog.

How to choose a software development company, and what to check first

Masoud Gorgani — Wed, 30 Sep 2026 15:16:18 +0000

Almost every supplier will show you a portfolio and a process diagram. Neither predicts how the engagement goes. These are the things that do, and most of them can be checked before you sign anything.

Start with the question you actually need answered

What a shortlist should actually test

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 — a feature that does not fit, 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

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

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.

Originally published on the Cognivise blog.