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.
In-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
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 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.