Web development technologies
Web projects rarely fail on the framework. They fail on the boundary between the browser and the server, on a platform decision nobody revisited, and on a modernization that became a rewrite. This page owns both halves. The two narrower indexes under it own one each.
01Capabilities
Four web builds, and where each one gets hard
The framework is rarely the hard part in any of them. What decides each is the line between what the browser does and what the server does.
Products with a public surface and an application behind it
Pages a search engine has to read, plus an application behind a login, in one codebase. The decision is where each page gets assembled, not which library draws it. Often a Next.js shape.
Operational systems and back offices
Dispatch boards, admin consoles and reporting screens over logistics and warehouse management platforms. The interface is the easy half. What the server promises, and who may see what, is the other.
Web systems that earn money and are slow to change
An unsupported PHP version, an ASP.NET estate nobody wants to touch, a framework several major versions behind. That is legacy modernization, and it happens without a feature freeze.
The server side behind the interface
The rules, the integrations, the queues and the data model, on Node.js, .NET or Laravel. Which one follows from the shape of the work.
02Stack
Client or server: which of these ten pages you want
Ten pages sit here, and every one also sits in a narrower cluster. Four answer for what the browser runs. Six answer for what the server runs. Each row has one destination, so the whole row is the link.
| Page | Where it sits, and when we reach for it |
|---|---|
| React | Default clientBrowser side. Our default for an application behind a login with real state to keep straight.React developmentOr book a meeting |
| Angular | Big estatesBrowser side. Routing, forms and data fetching decided once, which beats each team assembling its own.Angular developmentOr book a meeting |
| Vue.js | Add in placeBrowser side. The best of the three at being added screen by screen to an application you keep.Vue.js developmentOr book a meeting |
| Front-end development | The offerBrowser side, and the engineering offer rather than a stack. Start here to have the interface owned.Front-end developmentOr book a meeting |
| .NET | Long-lived coreServer side. Rule-heavy work several teams will still be changing in a decade, on a Microsoft estate..NET developmentOr book a meeting |
| ASP.NET | The web half of .NETServer side. The same platform, scoped to web applications and their hosting. Two different bills.ASP.NET developmentOr book a meeting |
| Node.js | One layer onlyServer side. Strong where the work waits on databases and other systems, or holds many connections open.Node.js developmentOr book a meeting |
| Laravel | New PHP workServer side. The strongest ecosystem in the PHP family, and what we would start something new on.Laravel developmentOr book a meeting |
| PHP | Modernize in placeServer side. A supported version, tests around the paths that take money, then refactoring. Re-platforming rarely pays.PHP modernizationOr book a meeting |
| Yii2 | Inherited estates onlyServer side. We maintain, rescue and migrate what already runs on it. Nothing new should start here.Yii2 maintenanceOr book a meeting |
03Fit
The decision is the boundary, not the framework
Most web decisions arrive framed as a framework choice. They are really three questions: where each page gets assembled, what shape the server work is, and whether to build custom at all. Two rows below start beyond this page, with a publishing platform or a measurement, and a third modernizes in place.
| Your situation | What we recommend |
|---|---|
| Public pages a search engine must read, plus an application behind a login | One codebaseReact through Next.js, deciding page by page where each one gets assembled. That choice matters more than the library, and it adds a server to run. |
| A large estate, several teams, several years, one upgrade path wanted | Decide it onceAngular in the browser, a strictly typed platform such as .NET behind it. At this size one settled way of working beats letting each team choose. |
| A working application you are keeping, where a few screens need to feel like a product | Screen by screenAdopt less, not more. Vue mounts onto the screens that need it. The rest does not have to be rebuilt in the browser first. |
| Mostly content, editorial and marketing, with a few forms | A publishing platformA ready-made publishing platform wins on cost and on launch date, and CMS and platforms is where that decision lives. We build on those platforms too, so the recommendation follows your content. |
| A PHP estate that earns money and has become slow to change | Modernize in placeKeep it on PHP. A supported version, tests around the paths that take money, then refactoring, before anyone proposes Laravel or a rebuild. |
| Pages are slow, users are complaining, and somebody is proposing a rewrite | Measure firstGet real numbers off the live system first. Most of what gets blamed on a framework is a database query, a call that should have been queued, or an image nobody resized. |
Scope
What we own is that recommendation and everything under it. The line between browser and server. What each side promises the other. What the screen shows when a call fails. Whether your engineers can keep changing the system after we stop. We work to ISO 27001:2022 and ISO 9001:2015, audited by Quay Audit UK. Four notes, because these pages overlap on purpose. Only the browser half, and front-end technologies is the narrower index. Only the server half, and back-end development is. Wanting the work owned rather than a technology named, and that is web development or front-end development. Not a web application at all, and mobile technologies is the next stop.
We start a web build by drawing the line between browser and server. That means deciding what gets assembled where and what each side promises the other. The browser framework and the server platform then follow from that line.
Yaroslav HavrylivSenior Engineering Manager, unicrew04Delivery
Four decisions, and only the last is cheap to change
The order matters more than the stack, because each decision narrows the next. The framework comes last for a reason: it is the only one you can still undo cheaply.
- Draw the line between browser and serverWhat gets assembled where, what each side promises the other, and what the screen shows when a call fails. Nearly every framework argument we have sat through was this argument, one level down.
- Pick the server from the shape of the workMostly waiting on databases, queues and other systems suits Node.js. A rule-heavy core meant to outlive its team suits .NET. Web-first work where PHP already fits suits Laravel. One hiring profile instead of two is a real saving, but argue it as that.
- Pick the browser side from the audience and the teamPublic and findable, or behind a login. One team or several. Replacing an application, or adding to one you keep. Those three answers settle it, and the detail is on front-end technologies.
- Put one whole slice in production earlyOne journey from browser to database, with real sign-in, real data and real error states, before anyone starts on breadth. Problems between the halves surface while they are still cheap.
05Trust
What changed after these systems shipped
- Weeks to hoursUpdate release timeWaiverKing's waiver-form platform, built on PHP and Yii2.
- 10,000-plusProducts manufacturedJewelCandle's ecommerce build, on Laravel.
- Double digit growthMaintained without a substantial increase in staffingMiniMoves order management, React over ASP.NET.
06Case studies
Web systems we have shipped, browser and server
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
eCommerceEcommerce software development for JewelCandleJewelCandle, a mid-size European manufacturer of scented products, sells across seven EU countries (B2B and B2C) via online shops.10,000-plusProducts manufactured
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
FoodtechDigital Transformation in Food IndustryOur client is an innovation-oriented group of food companies based in Germany that produces and distributes a wide range of products for well-known retail businesses and food services.
Knowledge ManagementSaaS for Digital ResearchesA SaaS solution that helps knowledge workers streamline research work involving a substantial amount of information.- ModernizationRewriting and migrating a legacy platform onto .NET Core (Global On Media)unicrew rewrote Global On Media's legacy code and migrated its servers onto .NET Core, React, and Stencil.js in one engagement.
07Client voices
Two clients, one on each half of the system
Shippable and well received web GUI for previously API only application. The whole team is highly dedicated to the success of the project and delivers the planned artefacts on time. We are very happy to have chosen Artelogic.
Up until a year and a half ago, I handled all the development and support of our application myself and I needed help. I brought in Artelogic, and it was one of the best business decisions I’ve ever made.
08Questions
Five answers before you brief anyone
Decide it page by page, not once for the whole product. Anything a search engine reads, or that a visitor waits on, is assembled on the server. Anything behind a login, where the same person stays for an hour, can be assembled in the browser. Most products need both, which is the case Next.js exists for.
Ask what the differentiating logic is. Pages, forms, a catalogue and a checkout, and a ready-made platform wins on cost and launch date: CMS and platforms is where that decision lives. A workflow no platform expresses, and a custom build is cheaper over five years. The common case is both, which is what most e-commerce work actually is.
No, and the split is deliberate. This page owns the whole system, browser to server, and the boundary between them. Front-end technologies owns the browser decision alone. Back-end development owns the server choice alone. Pages sit in more than one of the three, because the same technology answers a different question depending on which half you are deciding.
Yes, and on a system you already own that is often the sensible shape. Every engineer comes with ownership of the design, because the browser and server boundary gets set early and costs the most to move later: an architect outside the delivery team reviews it, and the work goes through our own QA practice. Team extension is managed teams.
A scoping call with an engineer who would work on it, not a sales conversation. If a system exists we ask for repository access beforehand, because half an hour in the code answers more than an hour of description. What comes back is written: the browser and server split, which technologies we would choose, and what we would leave alone. Work usually starts two to four weeks after we agree scope.
Services we deliver in Web Development
All servicesNot sure where the web decision actually sits?
Tell us what the system has to do, what exists today, and who will maintain it. You will get an engineer's read on the browser and server split, and which parts a ready-made platform already covers.