Web Development Services
Custom website development, headless Shopify storefronts, and frontends built onto systems you already run.
- Six years building for the web
- Shopify, Next.js, Remix, React
- Fixed scope before you commit
Some websites need rebuilding. Plenty just need the three things that are actually broken fixed. HelloDevs will tell you which, before quoting either. The interesting work sits at the edges — a storefront that outgrew its theme, a frontend that has to talk to four systems, a design nobody can build.
What usually brings people here
What usually brings people here
Most conversations with a web development company start with a symptom rather than a spec. These are the ones that come up most. Send the URL before the brief — about one conversation in four ends with a smaller recommendation than the one that was asked for.
| The situation | The usual answer |
|---|---|
| The site is slow and nobody knows why | Audit first. Often a handful of scripts and oversized images, not a rebuild. |
| The design is fine but every change needs a developer | CMS work, so your team can edit without a ticket. |
| A Shopify theme cannot do what the brand needs | Custom frontend on the Shopify backend, or deeper theme work if that gets there. |
| Marketing wants landing pages faster than development can ship them | Component-based build with reusable blocks. |
| The site cannot talk to the other systems the business runs on | API integration between the site and those systems. |
| There is a Figma file and no one to build it | Build from the design, with a conversation about anything that will not translate. |
| The site works but will not survive the next stage of growth | Rebuild the part that breaks first, not the whole thing. |
What gets built here
Four kinds of work, and they overlap less than they sound.
What “headless” actually replaces — the Liquid theme, and nothing else.
GraphQL, read-only
at checkout
Shopify as the backend, your own frontend on top
Shopify as the backend, your own frontend on top
This is the request HelloDevs gets asked about most and the one with the widest gap between what people expect and what it involves. Here it is in plain terms. Send the store URL and what the theme will not do — the reply will say whether headless is the answer, and will say no when it is not.
- What it actually meansShopify has two halves. The commerce engine handles products, variants, inventory, orders, customers, discounts and checkout. The Liquid theme is the storefront customers look at. Going headless keeps the engine and replaces the theme — the storefront becomes a separate application, usually Next.js, Remix or Shopify's own Hydrogen, that reads product and collection data through the Storefront API and hands the shopper to Shopify's checkout when they are ready to pay. Nothing changes in the Shopify admin: your team adds products the same way, orders arrive the same way, payments and fulfilment stay where they are.
- When it is the right callA brand experience no theme can carry — configurators, interactive lookbooks, unusual navigation, animation that a theme fights. A site that is equal parts content and commerce, editorial and guides sitting alongside products. Commerce inside an existing site or app, where products need to live inside it rather than on a separate store. Several storefronts on one catalogue, sharing one Shopify backend. Performance at a level a theme with a dozen apps will not reach. Or Shopify as one system among several, connected to a CMS, a search service, a PIM or an internal tool.
- When it is the wrong call, honestlyMost stores asking about headless do not need it. A well-built theme on current Shopify architecture handles the large majority of what brands want, costs a fraction, and launches sooner. Three things worth knowing first: frontend apps stop working — review widgets, popups, chat, loyalty and upsell apps hook into the Liquid theme and each needs an API-level replacement, which is the cost that surprises teams halfway through. You take on a codebase maintained by whoever you hire, not Shopify's ecosystem. And migrations lose search rankings when handled carelessly — this sinks more headless projects than performance ever does. If a theme rebuild gets you 80% of the outcome for a quarter of the cost, that is the recommendation you will get here.
- Hydrogen, Next.js, or staying on LiquidHydrogen is Shopify's own React framework, hosted free on Shopify's Oxygen platform and included with a Shopify subscription — the path of least resistance when Shopify is the long-term home and the project is commerce-first. Next.js or Remix when Shopify is one system among several, when there is heavy editorial content, or when the storefront needs to live inside a larger application. Liquid when the team is too small to sustain a React codebase, or when launching soon matters more than the ceiling — not a lesser answer, for most stores it is the correct one. The Storefront API is available on every Shopify plan: a storefront that lists products, runs a cart and hands off to standard checkout does not require Plus. Customising checkout itself, Shopify Functions, or higher API rate limits does.
- The lower-risk way inA headless rebuild does not have to happen all at once. One route — a product configurator, a single collection, a campaign page — can run on a new frontend at a subdomain or path while the existing theme serves everything else. More routes move across when each one is proven. Two rendering stacks running side by side is more work than a clean rebuild — it is also far less likely to take the store down on launch day.
Who edits the site after launch
Who edits the site after launch
The most common regret about a new website is not how it looks. It is discovering that changing a headline needs a developer.
- CMS development is decided before the buildWhich pages your team controls, which blocks they can rearrange, what they can create from scratch, and what stays locked so the design does not drift.
- Content lives in a CMS, not in the codeDepending on the project that means Shopify's own content tools, a headless CMS, or a custom admin — the choice depends on who is editing, how often, and whether the same content feeds more than one place.
- Blocks, not fixed pagesA page built from reusable components lets marketing assemble a new landing page from parts that already exist, instead of filing a request and waiting.
- Written instructions, not a handover callDocumentation for each editable area, so the knowledge does not leave with whoever attended the meeting.
Connecting the systems around the site
Connecting the systems around the site
Very few websites stand alone. Most need to exchange data with something, and this is where builds tend to slip. The unglamorous half of integration work is what happens when the other end is slow, down, or returns something unexpected — that gets built deliberately rather than discovered in production.
- CommerceShopify Storefront API and Admin API for products, carts, customers and orders.
- ContentA headless CMS, or Shopify's content tools where that is enough.
- Marketing stackEmail and SMS platforms, analytics, tag management, consent tools.
- SearchHosted search where a catalogue or content library has outgrown built-in search.
- PaymentsStripe, Shopify Payments, and region-specific gateways where relevant.
- Anything with an APIBooking systems, availability, pricing feeds, internal services.
The parts that decide whether it lasts
The parts that decide whether it lasts
These rarely appear in a brief and always appear in the complaints six months later.
- SpeedMeasured on a mid-range phone on a slow connection, because that is where most visitors actually are. Server-side rendering where it helps, images sized and served properly, third-party scripts loaded late or not at all. Core Web Vitals are reported before and after, not claimed.
- MobileDesigned and tested on real devices rather than a resized browser window. Most sites now see more mobile traffic than desktop, and it is usually the mobile experience that decides whether a visitor stays.
- SecurityDependencies kept current, secrets kept out of the codebase, forms protected against abuse, HTTPS and headers configured properly, and admin access limited to who needs it. Nothing exotic — the failures are almost always basics left undone.
- Staying maintainableCode written to be read by whoever comes next. Consistent structure, no clever shortcuts that only make sense to the person who wrote them, dependencies chosen for longevity over novelty, and the reasoning behind architectural decisions written down.
- Growing into itBuilt so the next stage does not mean starting again. More traffic, more products, more languages, more markets — the parts likely to change are the parts kept flexible.
Starting from what you already have
Starting from what you already have
Rebuilding from nothing is rarely necessary, and rarely the best value.
- An existing websiteIt can often be improved, extended or partly rebuilt rather than replaced. What exists gets reviewed before anything is quoted, including the answer that the current site is fine and only three things need attention.
- A Figma fileCustom website development from a finished design is straightforward. The useful part is the conversation first — a design review that flags anything that will behave differently in a browser, at other screen sizes, or once real content is longer than the placeholder.
- A design that is not finishedWireframes, references, or a clear idea are enough to start with. Design work happens alongside the build rather than blocking it.
- A part-built site someone else startedThe code gets read before any quote. Sometimes finishing it is the right call; sometimes it is not. Either way you get that answer in writing before spending anything.
- A working Shopify storeIt can stay exactly as it is while a new frontend is built alongside it, then switch over when it is genuinely ready.
Stay on your theme, rebuild it, or go headless?
Question 1 of 6
Does your current theme handle most of what the brand needs?
What you get
What comes with the build
Included in every quote. Anything an agency leaves out here reappears later as a change request.
- Scope documentWhat is being built, what is not, and what it costs to run.
- The site itselfResponsive, accessible, and fast on real devices.
- CMS setupWith the editable areas agreed in advance.
- Redirect mapFor any rebuild, so search rankings survive the move.
- Analytics and consentConfigured at launch, not retrofitted.
- Performance reportBefore and after, with real numbers.
- DocumentationHow to edit it, how to run it, how to change it.
- Source codeIn your repository from the first commit, with accounts in your name.
- Running cost estimateHosting and third-party services, monthly, before you commit.
- 30 days of post-launch fixesIncluded, not billed.
How a build runs
Five steps, staging updated every week
Feedback while things are still cheap to change rather than at the end.
- ReviewThe current site, the design, or the idea. What comes back is a plain assessment of what is worth doing — including the smaller version, when the smaller version gets there.
- Fixed scope and priceIn writing, with what is excluded stated as clearly as what is included. Not an hourly estimate that grows.
- Build in weekly cyclesA staging URL updated every week. Feedback while things are still cheap to change rather than at the end.
- Test and launchReal devices, real connection speeds, redirects mapped before anything goes live, and a launch window chosen around your traffic rather than the development calendar.
- AfterwardsThirty days of fixes included. A maintenance arrangement if you want one, and no obligation if you would rather handle it yourself or elsewhere.
Our stack
Pure-play Shopify developers
We develop only for Shopify. No bloated frameworks, no visual page builders that degrade site performance, and no subcontracting. Just clean, hand-crafted code.
The Frontend Stack
Listed because technical buyers ask, and because a vague answer here usually means the work is being passed to someone else. React, Next.js, Remix, TypeScript and modern CSS, server-side rendering where it earns its place. On Shopify: Liquid and current theme architecture, Storefront API and Admin API over GraphQL, Hydrogen, theme app extensions and checkout extensibility. Nothing is subcontracted — the people on the first call are the people writing the code.
- React
- Next.js
- Remix
- TypeScript
- Hydrogen
- PostgreSQL
- GraphQL
- app/routes/products.$handle.tsx01
- lib/shopify/storefront.ts02
- components/cart/CartDrawer.tsx03
- cms/schema/page.ts04
One API, Any Frontend
Node.js, TypeScript, REST and GraphQL APIs, PostgreSQL, MongoDB, Supabase — the same layer whether the frontend in front of it is a marketing site, a headless storefront or a logged-in platform.
const { products } = await storefront.query(
PRODUCTS_QUERY
);No Subcontracting
Nothing is subcontracted. The people on the first call are the people writing the code, on the frontend and everything it talks to.
offshore-handoff.zip
CMS, Not Hardcoded
A headless CMS, Shopify's own content tools, or a custom admin — whichever fits who is editing, how often, and whether the same content feeds more than one place.
ReviewLaunch
Web development services: common questions
- Headless Shopify means keeping Shopify as the commerce backend while replacing its Liquid theme with a separate custom frontend. Shopify still handles products, inventory, orders and checkout; the storefront customers see is a separate application reading data through the Shopify Storefront API.
- Yes. A custom frontend built in Next.js, Remix or Hydrogen can read products, collections and customer data from Shopify and pass the shopper to Shopify's checkout. Your Shopify admin does not change — products, orders and fulfilment work exactly as before.
- Not necessarily. The Storefront API is available on every Shopify plan, so a storefront that lists products, runs a cart and uses Shopify's standard checkout does not require Plus. You do need it for checkout customisation, Shopify Functions, and higher API rate limits — which is why most large headless builds end up on Plus.
- Backend apps will — payments, shipping, fulfilment, inventory and accounting keep running normally. Frontend apps will not: review widgets, popups, chat, loyalty and upsell tools hook into the Liquid theme and need an API-level replacement or a custom build. This is the most commonly underestimated cost of going headless.
- Improve the theme, unless it genuinely cannot do what the brand needs. Current Shopify theme architecture handles most requirements at a fraction of the cost and launches sooner. HelloDevs will say which one applies to your store before quoting either.
- Yes, and it is one of the more common requests. Products, carts and checkout can be embedded into an existing site or application through the Storefront API, so commerce lives inside your site rather than on a separate store.
- Yes. A design review comes first, flagging anything that will behave differently in a browser, on other screen sizes, or with real content instead of placeholder text. Catching those before the build is considerably less expensive than catching them in review.
- Usually, and it is worth checking before committing to a rebuild. What exists gets reviewed first, and if the honest answer is that three fixes get you the result, that is the answer you will get.
- Yes, and which parts are editable is agreed before the build starts. Content lives in a CMS rather than in the code, pages are assembled from reusable blocks, and each editable area is documented. If a headline change needs a developer, the site was built wrong.
- A focused marketing or brand site takes four to eight weeks from approved design. A headless Shopify storefront takes twelve to twenty weeks depending on how much of the frontend app functionality has to be rebuilt. A site with logged-in areas sits in between. Every quote comes with a date against a written scope.
- They are protected deliberately, or they are lost. URL structure is preserved where possible, every changed URL gets a redirect, content is server-rendered so it can be crawled, and structured data moves across with the build. Careless migration causes more damage on headless projects than any performance issue.
- Yes, completely, from the first commit. The repository is yours and hosting and third-party accounts are in your name. If you stop working with HelloDevs, nothing about your website depends on us.
- Hosting, CMS, third-party services and any maintenance arrangement — all estimated before you commit. A build quote without a running cost is half a quote, and the other half turns up after launch.
- The current site URL if there is one, whatever design exists, a description of what is not working, and who inside the business will edit the site afterwards. That is enough for a real assessment. A full specification is not required and is often better written together.
Send the URL, not the brief
A current site or a design tells more than a specification does. A developer at HelloDevs will look at it and reply within one business day, including if the recommendation is smaller than what you asked for.
Our talk
Send the URL, not the brief
A current site or a design tells more than a specification does. A developer at HelloDevs will look at it and reply within one business day, including if the recommendation is smaller than what you asked for.
