Back-end development
The runtime, meaning the language and platform your server code runs on, is settled by what the system must guarantee and by who will still be changing it in three years. Not by a benchmark. Below is that rule, run across all fifteen pages in this cluster, including the cases where the answer sits outside them.
01Capabilities
Four kinds of server system, and what breaks each one
The back end is where your business rules live, and the rules outlive everyone who wrote them. Four shapes account for most of our custom software development work.
Transactional business platforms
Order management, dispatch and billing, the shape behind our logistics work. Staying correct when two things happen at once matters more than any framework preference.
APIs: the agreed way other systems call yours
We design that agreement first. It is what you cannot cheaply change once three other systems depend on it, and in fintech it is what an auditor reads.
Integration between systems never designed to talk
Warehouse systems, payment providers, monitoring hardware in healthcare. Handling repeats, ordering and reconciliation is the engineering, not the happy path. That is platforms and integration work.
Background, batch and scheduled processing
Queue consumers, imports, exports, nightly reconciliation. What happens on a restart, a cancellation or a half-finished run decides whether these stay boring.
02Stack
Fifteen runtimes, and the ones we would actually reach for
One row per page in this cluster, with our verdict and the honest reason. The whole row is the link. Estate below means the servers and systems you already run.
| Technology | When we reach for it |
|---|---|
| .NET | DefaultThe platform and hosting decision for a rule-heavy business system in a Microsoft estate..NET developmentOr book a meeting |
| C# | The languageSame estate, when the question is the code rather than the platform.C# developmentOr book a meeting |
| ASP.NET | Web tierSame estate again, when you are building a web application or the service behind one.ASP.NET developmentOr book a meeting |
| Java | Java estatesThe same system where the servers, the operations and the people are already Java.Java developmentOr book a meeting |
| Java EE and Jakarta EE | Inherited onlyEnterprise Java tied to an application server such as WebLogic or JBoss. Nothing new starts here.Java EEOr book a meeting |
| Python | Data and modelsAnywhere data, analytics or a machine-learning model sits near the core of the product.Python developmentOr book a meeting |
| Django | Business appsThe Python choice when the product is a database-backed application needing staff screens early.Django developmentOr book a meeting |
| Go | ThroughputNetwork services under heavy traffic, where handling many requests at once is cheap.Go developmentOr book a meeting |
| Rust | Hard limitsOnly where a pause for memory cleanup would breach a written response-time limit, and then as one bounded part.Rust engineeringOr book a meeting |
| PHP | ModernizeAn estate that already earns money: raise the versions, test the paths that take money, then restructure.PHP modernizationOr book a meeting |
| Laravel | New PHP workThe answer to what to build new in PHP, and not the answer to what to rewrite.Laravel developmentOr book a meeting |
| Yii2 | Maintain onlyA live application people are nervous about touching. Keep it current and tested; start nothing new on it.Yii2 maintenanceOr book a meeting |
| Ruby and Rails | Keep what runsA working Rails application is worth keeping. We extend and maintain rather than replace.Ruby and RailsOr book a meeting |
| C++ | Engine workProcessor-heavy work inside an ordinary application, or one native library several languages must call.C++ developmentOr book a meeting |
| C | Bare metalFirmware, drivers and vendor toolchains where memory is counted in kilobytes. On a full operating system we argue for C++.C developmentOr book a meeting |
03Fit
Two questions settle a runtime, and sometimes the answer is the one you run
What must this system guarantee, and who is still changing it in three years. Those two settle most cases inside one call. Nothing we earn depends on which runtime you choose, so the answer follows your system, and half the rows below keep the language you already run.
| Your situation | What we recommend |
|---|---|
| A rule-heavy transactional core in a Microsoft estate, expected to outlive its team | .NETTake the platform decision first, then the code. For a web application the answer is ASP.NET. Three different bills, and people arrive calling all of them one name. |
| The same system, but the servers, operations and people are already Java | JavaSpring Boot, which is what most Java teams already run. Changing platform to fix a working estate almost never pays. |
| Data, analytics or a machine-learning model anywhere near the core of the product | PythonNot a close call. If it is really a database-backed business application needing staff screens early, the framework is the decision and that is Django. |
| A product that spends its time waiting on a database or a third party, and one team writing TypeScript | Outside this clusterOne language across the whole stack beats a faster runtime in a small team. Node.js sits under web development here, not in this cluster. |
| A PHP or Rails application that already earns money and is slow to change | Modernize in placeRaise the versions, test the paths that take money, then reshape what is there. That is legacy modernization, and a rewrite is the expensive route to the same place. |
| Everything feels slow, and the language is getting the blame | Keep the languageLook first at how the database is queried, at work done while the caller waits that should be queued, and at releases that force everything out together. |
Scope
A language nobody on your staff can maintain costs more in year two than it saves in month one. The slowness people blame on a language usually sits in the three places named above, all fixable where they are. What we own is the design and what follows from it: the rules the system enforces, what it does when something fails, the line between one service and the next, and whether your engineers can keep changing it after we step back. We work to ISO 27001:2022 and ISO 9001:2015, audited by Quay Audit UK. unicrew has been building software since 2012, as Artelogic until the rename, with 100+ senior in-house engineers across six countries and 120+ projects delivered across 12 countries.
We pick a runtime from what the system has to guarantee and who will still be changing it in three years. Those two questions settle most cases inside one call. We write the decision down, with what we rejected and why.
Oleksandr TrofimovChief Technology Officer, unicrew04Delivery
Guarantees first, runtime last
Four steps, usually inside an hour. The runtime comes last because it is the cheapest of the four to change later, and we write the result down: the reason is the first thing to get lost.
- Establish what the system has to guaranteeCorrectness, speed, volume, audit trail and where data is allowed to live, written as constraints rather than preferences. In a regulated sector the regulator sets them, not you: GDPR in the EU, and the sector rules above it. Most back-end arguments are two people optimising for different guarantees without saying which is in the contract.
- Look at what you already run, and who maintains itThe existing estate, the operations team you have, and the hiring market where the system lives. This decides the answer most often, and it is the input people skip in favour of a comparison table.
- Fix the boundaries before the runtimeWhat this service owns, what it never touches, what it exposes to others. Boundaries cost far more to change later than the language inside them does.
- Write the decision down, including what we rejectedOne page: the choice, the constraints it satisfies, what we turned down and why. It is also what makes an independent verdict possible later, which is what a quality audit is for.
05Trust
What changed for clients after the back end did
- 15-20%Increase in revenueA paddle sports centre in California, client-reported, after we modernized their platform on PHP, Yii2 and Java.
- 600+Businesses using the platformBooked It, on the Laravel back end we built for them.
- 2xData-entry throughputA custom recognition tool we built in C#.
06Case studies
Six back-end systems, and the outcomes published with them
SaaSWaiverKing: Software Development for Waiver Form CreatorWaiverKing is a document management business serving primarily the health and fitness industries. The platform is partnered with MindBody Online, one of the largest business-systems providers for gyms and yoga studios.Weeks to hoursTime for an update to reach live
HospitalityHighly Adjustable Platform for entertainment industriesunicrew developed a platform for Booked It that enhanced the customer experience for nightclub, entertainment center, and festival goers.600+Businesses using the platform- AutomationDoubling data-entry throughput with a custom recognition toolunicrew automated a manual data-entry bottleneck with a C# and AWS recognition tool, doubling the data sets the team got through each month.2xData sets processed per month
LeisureSaaS modernization for Paddle Sports Center in CaliforniaA kayaking and paddleboard rental business in the Santa Barbara area wanted one system for equipment, customers, time and billing. That system is Adventure Rental System.15-20%Increase in revenue
LogisticsMiniMoves Orders Management PlatformA custom-built moving order system that simplifies booking, boosts automation, and improves operational efficiency.Double digit growthMaintained without a substantial increase in staffing
LogisticsCustom software for USA moving companyAn end-to-end SaaS platform for managing household moves and every business operation of a logistics company.Built from scratchAn end-to-end SaaS for household moves and the operations behind them
07Client voices
Five clients, in their own words
They’ve been helping us grow our platform together since the beginning, from a couple hundred companies to around 2,000. Artelogic has been front and center in this process.
Our platform has been refactored to Laravel ensuring the code base is more stable, easier to maintain and easier to add new features. Their professionalism and quality of work have stood out in the partnership. We have had the code audited by a 3rd party who was extremely complimentary of the work.
I’ve been impressed by their work ethic and how they put me as the customer first. They’re always ready to jump in and go the extra mile. They put great effort into communicating to ensure that tasks are updated in a timely manner. The team keeps us apprised of exactly what they’re working on.
Site was migrated and re-written, the new system is much more stable, and performance highly improved. Excellent technological level. highly responsive and communicative. They are highly committed to the project and business goals.
The quality of their coding was outstanding to our standards. Overall, their work was key for us. They were dedicated to solving our problems as a customer; their team was collaborative, listened to us, and fully engaged in our space to commit to the project.
08Questions
The questions buyers put to us before signing off a runtime
You can bring our engineers into your team, and when you own the roadmap that is often the right shape. Every engineer comes with ownership of the design, because the decisions that cost most to change here are what each part owns and how it reaches the data: an architect outside the delivery team reviews the design, and the work goes through the same QA practice as our own. Team extension is managed teams.
Yes, and the sequence is the same whatever the language. We map what actually runs rather than trusting the handover pack. We put tests around the behaviour that pays your bills before changing any of it. Then we bring the language and library versions up to date, because nothing else can move until that is done. The first weeks go into that groundwork, which is what lets later changes land safely.
Most of the sequence above exists for this. Every runtime and boundary decision is written down with what we rejected, so the reasoning does not leave with a person. An architect outside the delivery team reviews the design, so more than one person can explain the system. And the behaviour that pays your bills sits in tests rather than in somebody's memory.
If the system already exists, by asking for read access to the repository first: an hour inside the code moves an estimate more than three hours of description. The call is then with an engineer who has read it. What comes back is written: the recommendation, what we would change first, what we would leave alone, and what we rejected. Work usually starts two to four weeks after we agree scope.
Services we deliver in Back-end Development
All servicesNot sure which runtime your system belongs on?
Tell us what the system has to guarantee, what it talks to, and what your team already writes. You will get an engineer's read on the choice, including the version where the language was never the decision.