Comparisons
Straight comparisons, including when to pick the other one.
On some of these we are one of the options, and on others we have no stake at all. Either way each page names the conditions where the alternative wins, because a comparison that always ends the same way is an advert, and you would spot it anyway.
Contact centre platforms
What to run your dialling and call handling on, and when the commercial platform is the better buy.
VICIdial vs Genesys Cloud
One is an open-source contact-centre suite you own and operate. The other is an enterprise CCaaS platform you subscribe to and hold a vendor accountable for. The right answer depends far more on your organisation than on the software.
Read the comparisonVICIdial vs Five9
Two credible ways to run an outbound or blended floor: software you own and operate, or a cloud contact centre you subscribe to and switch on quickly. The deciding factors are speed, staffing and what your CRM story needs to look like.
Read the comparisonVICIdial vs Amazon Connect
These two are usually bought by different people for different reasons. One is a contact centre platform you consume from AWS alongside everything else you run there, the other is software you own, size and operate yourself.
Read the comparisonVICIdial vs Twilio Flex
Two very different bets: a complete contact-centre application you host yourself, or a programmable contact centre you extend in React on somebody else’s carrier network.
Read the comparisonVICIdial vs 3CX
One is a business phone system with contact centre features available on top. The other is a campaign dialling platform. Most of the time the right question is not which one wins, it is which job you are actually trying to do.
Read the comparisonVICIdial vs Asterisk
These two are not competitors. One is a telephony engine, the other is a contact centre application built on top of it. The real question is whether your requirement is campaign shaped.
Read the comparisonVICIdial vs GoAutoDial
The closest thing to a genuine rivalry in this space, and it is still narrower than it looks: one is a distribution built around the other’s engine.
Read the comparison
How to engage a team
How to buy engineering, rather than what to build with. We are one of the options on these pages, which is exactly why they say when we are the wrong one.
Freelancer vs Software agency
One person or a firm. A good freelancer is the best value in software for well-defined, single-skill work. An agency earns its higher rate when the work spans several skills, has to survive any one person being unavailable, and needs someone other than its author to check it.
Read the comparisonIn-house team vs Outsourced development
Two legitimate ways to get software built: employ the engineers yourself, or contract the capability from outside. The deciding factors are whether the capability needs to be permanent, whether you can genuinely hire and keep it, and how much of your business knowledge has to stay in the building.
Read the comparisonStaff augmentation vs Dedicated team vs Fixed-scope project
Three ways to buy engineering capacity that are sold as if they were sizes of the same thing. They are not. They differ in who owns the outcome, and choosing on price rather than on ownership is the most common reason these engagements disappoint.
Read the comparisonOffshore vs Nearshore vs Onshore
These three words describe distance from you, not quality. The useful question is not which is best, it is how much synchronous collaboration your work genuinely needs, and what your legal, regulatory and procurement constraints will actually permit.
Read the comparisonFixed price vs Time and materials
Two ways to buy software delivery: a number agreed in advance against a defined scope, or payment for the effort actually spent. The choice is really about who carries the risk of the estimate being wrong, and whether the scope is knowable enough for anyone to price it honestly.
Read the comparison
Build or buy
Whether to write software at all. We build custom software for a living, and both pages open by telling most readers to buy.
Custom software vs Off-the-shelf software
Build something that fits exactly, or buy something that already works and adapt to it. For most of what a business runs, buying is the right answer, and the case for building is narrower and more specific than suppliers on either side tend to admit.
Read the comparisonLow-code and no-code vs Custom development
Visual platforms let you assemble working software quickly, often without professional developers. Custom code takes longer to start and has no ceiling. The deciding questions are how complex the logic will become, how many people will use it, and how long it has to live.
Read the comparison
Websites and e-commerce
Platform or custom build, for the site and the store. The honest answer for most small businesses is the platform.
WordPress vs Custom-built website
One is a ready-made content system you configure and extend. The other is a site written for you in code, usually on a framework such as Next.js with a headless CMS behind it. For a great many company websites the first is the right answer, and the second earns its cost only in particular conditions.
Read the comparisonShopify vs WooCommerce
One is a hosted platform you rent by the month. The other is a free plugin that turns a WordPress site you run into a shop. The real choice is between paying a platform to carry the operations and carrying them yourself in exchange for control.
Read the comparison
AI and automation
What to build an assistant, an agent or an automation on, and when the simpler option is the right one.
Chatbot vs AI agent
A chatbot answers in conversation and leaves the decision with the person reading the reply. An AI agent plans and takes actions through tools on your systems. The real question is how much work you are willing to let software do unsupervised, and what it costs you when that work goes wrong.
Read the comparisonRAG vs Fine-tuning
Retrieval-augmented generation changes what a model sees at the moment it answers. Fine-tuning changes how the model behaves. Most teams asking which they need have either a knowledge problem or a behaviour problem, and a good share have one that clearer prompting would fix for far less than either.
Read the comparisonn8n vs Zapier vs Make
Three tools for wiring systems together without writing an integration from scratch. Zapier and Make are hosted services you rent, and n8n can be rented or run on your own servers. What decides it is who will build and own the automations, how often they will run, and where your data is allowed to go.
Read the comparisonWhatsApp Business app vs WhatsApp Business Platform (API)
Two products that share a name and little else. The free app is a phone-based tool for a small team replying to customers by hand. The platform, reached through Meta’s Cloud API, is infrastructure for software: many agents, chatbots, CRM integration and messages your systems send themselves, billed per message.
Read the comparison
Technology choices
The decisions that are cheap to make now and expensive to reverse later. We have no stake in these answers, so they are simply what we would pick.
React vs Next.js
Every Next.js application is a React application, so the real question is narrower than the search suggests: React on its own, usually built with Vite, or React inside a framework that adds routing, server rendering and a deployment model. Search visibility, hosting and your team’s appetite for running a server usually decide it.
Read the comparisonReact vs Angular vs Vue
Three mature ways to build a web front end, built on different beliefs about how much should be decided for you. React is a library you assemble an application around, Angular is a complete framework with the decisions already made, and Vue sits deliberately between the two. Team, lifespan and hiring settle it far more often than performance does.
Read the comparisonLaravel vs Node.js
One is a complete PHP framework with most decisions already made, the other is a JavaScript runtime you build a framework stack on top of. The fair comparison is Laravel against Express, Fastify or NestJS, and it usually turns on the shape of your workload and the language your team already writes.
Read the comparisonMongoDB vs PostgreSQL
A document database built around flexible records and native sharding, against a relational database that also stores and indexes JSON well. The choice rests on the shape of your data, the questions you will ask of it later, and whether your writes will ever outgrow a single machine.
Read the comparisonNative apps vs Cross-platform apps
Build each platform in its own language, or build once and ship to both. The useful comparison is about how many codebases you are prepared to own, how close to the operating system your product has to sit, and who will still be maintaining it in three years.
Read the comparisonMicroservices vs Monolith
One deployable application with firm internal boundaries, or many small services that are deployed, scaled and broken separately. Most teams should start with the first, and the conditions that justify the second are specific enough to check against your own organisation.
Read the comparisonReact Native vs Flutter
Two mature ways to build one app for iOS and Android. One drives the platform’s real native components from React, the other draws every pixel itself from Dart. The deciding factor is usually what your team already knows, and it is worth being honest about that.
Read the comparisonAWS vs Azure vs Google Cloud
Three capable platforms, and a decision that is almost never won on a feature grid. What actually decides it is your existing estate, your team, your residency obligations, your procurement position and how much exit cost you are willing to carry.
Read the comparisonPostgreSQL vs MySQL
Two mature, free, thoroughly proven relational databases that will both outlive your application. The choice comes down to what you already run, what your data actually looks like, and which set of operational habits your team is willing to build.
Read the comparisonDocker vs Kubernetes
These two are compared constantly and they are not competing products. The question hiding behind the search is whether your containers need an orchestrator at all, and if they do, whether it has to be Kubernetes.
Read the comparison
Not sure which of these fits?
Tell us what you are actually deciding between and what constrains it. We will tell you which one we would choose in your position and why, including when that is not the one we sell.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.