Frequently Asked Questions

Anything from a product you can rotate and inspect directly in the browser, to a scroll-driven scene that unfolds as you read, to a full interactive configurator where a customer builds their own version of what they are buying. The common thread is WebGL rendering natively inside the page itself — no plugin, no separate app to download, and it works on whatever device someone already has open.

It is additive to a standard build rather than a separate project — expect it to add a meaningful chunk to the timeline and budget depending on how many objects need modelling and how much interactivity the scene needs. A single rotating product view is a modest addition. A full configurator with multiple materials, colours, and camera angles is closer to its own mini-project. We scope it after seeing what you actually want someone to be able to do with it, not before.

It can, if it is bolted on carelessly — that is the reputation 3D web work has earned itself. We budget the scene like any other asset: model complexity, texture size, draw calls, all measured against a performance target, and we load it after the core page is already interactive. The part someone came to read is never waiting on the part they came to admire.

That is where most of the tuning effort goes, because it is where most 3D web projects quietly fail. We test on mid-range Android hardware, not just a developer's laptop, and we build a simplified fallback scene for devices that genuinely cannot carry the full experience — rather than serving everyone the heaviest possible version and hoping for the best.

Honestly, most businesses do not, and we will tell you that plainly during discovery rather than sell you a scene you do not need. It earns its cost when the product itself is the sell — furniture, fashion, hardware, jewellery, anything where seeing it rotate and catch the light changes someone's decision to buy. If your product is a service or a straightforward physical item photographed well, that budget is usually better spent elsewhere.

It comes down to how unusual your operation is and how much control you want. Shopify wins on simplicity — hosting, security, and PCI compliance are handled for you — at the cost of a transaction fee on every sale and less flexibility to do something genuinely custom. WooCommerce wins when you need custom logic (unusual shipping rules, a wholesale tier, a subscription model that does not fit a standard app) or your volume makes those Shopify fees add up to real money. We look at your actual product catalogue and order volume before recommending either, rather than defaulting to whichever we prefer building.

Nearly always the same handful of reasons, in roughly this order of damage: forced account creation before they can even see the total, a shipping cost that only appears on the final step, and a long form that is painful to fill on a phone. Each one is fixable — guest checkout, upfront shipping estimates, and a form that autofills what it can — and checkout optimisation usually returns more revenue per hour of work than almost anything else we could spend that budget on.

Yes — that is one of the more common reasons people call us in the first place. Where the system has a documented API (most modern accounting and inventory platforms do), we integrate directly. Where it does not, we build the middleware ourselves rather than telling you it cannot be done. The goal is always one accurate source of truth, so your storefront, your warehouse, and your finance team stop disagreeing about what is actually in stock.

Card details never touch your own server — every payment is tokenised directly through the gateway (Stripe, PayPal, or your regional equivalent), which keeps you in the simplest PCI compliance category available rather than one that requires an expensive annual audit. On top of that we enforce HTTPS everywhere, keep dependencies patched, and never store anything more sensitive than we absolutely need to. Security on a store is not a feature you add later; it has to be the default from the first commit.

That is exactly the kind of scalability question worth asking before launch, not after your site falls over during a Black Friday campaign. We load-test against realistic peak scenarios, use caching and a CDN so most traffic never touches your origin server, and choose hosting that can scale horizontally when it needs to. If your growth plans include a specific big moment — a product drop, a seasonal spike — tell us the numbers you are expecting and we will build and test against them specifically, rather than a generic "should be fine."

Cross-platform (Flutter or React Native) covers the large majority of business apps well and roughly halves both the build cost and the ongoing maintenance cost, since one codebase ships to both the App Store and Google Play. Native earns its place when the app leans hard on device-specific capability — heavy camera or AR work, background processing that needs to be bulletproof, or a platform-exclusive integration. For most booking apps, portals, and internal tools we recommend cross-platform, and we will tell you plainly if your specific use case is the exception.

More than a website with similar functionality, mainly because of store submission overhead and the extra testing that two platforms demand. A focused app with a handful of core screens — sign-up, a main flow, a profile — sits meaningfully above a comparable website. Real-time features, payments, or offline sync each add their own chunk on top. We scope this properly once we know exactly what the app has to do, rather than throwing out a number before that conversation happens.

A focused app with a handful of core screens is typically ten to fourteen weeks including store submission. Apple's review process alone can add several days per submission cycle, and it is common to get a question back on the first attempt — we budget that in rather than treating it as a surprise. Anything with real-time features, payments, or offline sync usually needs longer, and we will give you an honest number once we understand the actual feature list.

Yes, including the parts people usually get stuck on — writing a privacy policy that actually matches what the app does, preparing screenshots at every required device size, and responding to Apple's review notes when the first submission gets flagged, which happens more often than most first-time app owners expect. We manage the developer accounts under your ownership, not ours, so you are never dependent on us to publish an update later.

Both platforms update yearly, and it is genuinely common for something to break in the process — a permission dialog changes, an API gets deprecated, a review guideline tightens. Apps under a maintenance retainer get tested against the beta releases before the public rollout, so a compatibility issue gets caught and fixed before your users ever encounter it, rather than showing up as a wave of one-star reviews the week iOS 19 ships.

The technical foundations are always included and non-negotiable: clean semantic markup, sensible URL structure, structured data, fast page speeds, and a proper redirect plan if you are migrating. That is what makes the site capable of ranking. Ongoing SEO — content strategy, keyword targeting, earning backlinks — is a separate, continuous programme rather than a one-time task, because it is a different kind of work entirely and it is the bigger lever once the technical foundation is sound.

It scales with how competitive your market is and how many channels you want running. A single-channel programme — SEO content, or one paid channel — run properly is a meaningfully smaller monthly commitment than trying to run four channels at once on the same budget, and spreading a small budget thin across everything reliably teaches you nothing about any of it. We would rather start you on one channel with enough spend to reach statistical significance than sell you a scattered package that looks impressive on paper.

Paid channels produce signal within weeks — you will know within a month whether the targeting and messaging are working. Organic SEO compounds over three to nine months, because it depends on content being published, indexed, and gradually earning authority. Anyone promising page-one rankings in thirty days is either targeting search terms nobody actually uses, or using tactics that will eventually cost you a penalty. We would rather set that expectation honestly on day one than have the conversation defensively in month four.

No, and we would recommend firing any agency that does. Bought links breach Google's guidelines directly and put your entire domain at risk of a manual penalty — a short-term ranking bump that reliably reverses, sometimes taking your legitimate rankings down with it. We earn placements by producing content and data genuinely worth citing. It is slower to show up in a report, and it does not evaporate the next time Google runs a core algorithm update.

Usually, but it starts with proper diagnosis rather than immediate action. A sudden drop can be a Google algorithm update, a technical regression from a recent site change, damage from a migration that lost redirects, or in rare cases a manual penalty — and the fix is completely different in each case. Anyone who starts "fixing" things before identifying which one actually happened is experimenting with your traffic, not solving the problem.

Some form of it on every project, even if that means three structured user interviews and an analytics review rather than a full six-week study — the depth scales with the budget and the stakes. Designing an interface without any evidence of how people actually behave is just guessing expensively, and even a small amount of research usually overturns at least one assumption the whole team had walked in with.

It depends heavily on scope — a logo refresh with a basic style guide is a much smaller engagement than a full identity system covering print, digital, signage, and social templates. What we always push back on is a client asking for "just a logo," because a logo with no supporting system tends to get applied inconsistently within six months and the brand ends up looking improvised. We would rather scope the smaller version of the complete system than the larger version of an incomplete one.

Yes, and it consistently produces a stronger result than doing the two separately with a gap between them. When the visual identity and the interface are designed against each other from the start, decisions about colour, type, and tone get made once, in context, instead of one project quietly working around constraints the other never knew existed. If you already have a brand, we design to it faithfully; if it exists but has never really been applied to digital, we extend it rather than override it.

A logo suite in every file format you will realistically need (vector, transparent PNG, favicon sizes), a documented colour and typography system with the exact values, written usage guidelines covering what not to do as much as what to do, and templates for the assets you will use most often — social posts, presentation decks, email signatures. Not a single logo file in a folder and a goodbye email.

You see working prototypes early and often, not a single "big reveal" after weeks of silence. Feedback happens in structured rounds with a defined number of revisions built into the original scope, so your input has a clear place to land instead of arriving as a constant stream of ad hoc requests mid-build that quietly blow the timeline. If a request falls outside the agreed rounds, we tell you what it costs before doing it, not after.

Where AI genuinely helps — summarising long documents, classifying support tickets, powering a smarter search, drafting a first version of routine copy — yes, and we build it properly. Where it is being requested because AI is simply expected to appear somewhere on the roadmap, we push back and say so directly. An AI feature that is confidently wrong ten percent of the time can cost more customer trust than it saves in staff time, so it has to earn its place like any other feature.

Most automation work is priced closer to a focused software feature than a full platform, because it usually plugs into systems you already have rather than replacing them. A single well-defined automation — routing enquiries, generating a report, summarising submissions — is a modest, contained project. Something that touches multiple systems and needs ongoing model tuning costs more and needs a proper scoping conversation, which is exactly where we would start rather than quoting blind.

Usually yes, and it is often the single highest-value work we do for a client because the time savings repeat every week indefinitely. We start by watching how the task is actually performed day to day, not how the process document claims it works — those two versions are rarely the same, and the gap between them is usually where the real automation opportunity is hiding.

We choose providers and configurations that explicitly keep your data out of third-party model training — that is a setting, not a given, and we check it rather than assume it. Where the data is genuinely sensitive — customer records, financial details, health information — we prefer self-hosted models or enterprise-tier agreements with a clear data processing contract over whichever API happens to be cheapest that month. Cutting a corner here is exactly the kind of decision that looks fine until it very publicly is not.

Almost never, and building a custom model is usually the expensive way to solve a problem a well-prompted existing model already handles well. We reach for a genuinely custom-trained model only in the small minority of cases where off-the-shelf models demonstrably cannot do the job — highly specialised domain language, for instance. If someone is proposing a custom model as the first option rather than the last, it is worth asking why.

Often you would be better served by off-the-shelf tools, and we will tell you that plainly during discovery rather than sell you a platform you did not need. Plenty of problems that sound like they need custom software are actually solved by a good website and two or three well-built automations. Custom software earns its cost when your process is genuinely unusual, or when an off-the-shelf tool is forcing your team to work around its limitations rather than the other way around.

This varies more than almost any other question on this page, because "custom software" covers everything from a simple internal dashboard to a multi-tenant SaaS platform. What we can tell you honestly: the first release should be scoped as narrowly as possible to prove the core value, not built as the full vision on day one. A focused MVP is a fraction of the cost of the complete platform, and it tells you — with real usage data — whether the rest is worth building at all before you spend on it.

Node and PHP most often on the back end, React or Next.js on the front end, and PostgreSQL or MySQL for data — chosen because they are well-understood, well-documented, and easy for another team to pick up later, not because they are fashionable. We are equally comfortable working inside a stack you already have rather than replacing it for its own sake; a rewrite is rarely the answer when the actual problem is one slow database query.

Usually, and this is one of the most common reasons clients come to us in the first place. Where a system exposes a documented API, we integrate directly against it. Where it does not — and plenty of older enterprise systems genuinely do not — we build the middleware ourselves rather than telling you it cannot be done. The underlying goal is always the same: one accurate source of truth, instead of three systems that quietly disagree with each other by Friday afternoon.

We design the architecture with your realistic three-year trajectory in mind, not just what the launch version needs to handle — that means choosing a database structure that will not need a rewrite at ten times the current data volume, and infrastructure that can scale horizontally rather than requiring a bigger single server every time traffic doubles. Scalability is a design decision made in week one, not a patch applied in a panic during month eighteen when it turns out to matter.

Dependencies get audited for known vulnerabilities on a schedule, not just at launch. Every input is validated server-side regardless of what the front end already checks. Secrets and credentials never live in the codebase itself. Access control is built around the principle that a compromised account should be able to do as little damage as possible. None of this is exotic — it is a checklist we run on every project, because the overwhelming majority of real-world breaches exploit something ordinary and unpatched, not something exotic.

You do, fully — the code itself, the infrastructure it runs on, and the documentation explaining how it all fits together. There is no technical dependency on us to keep it running. Most clients keep us on for ongoing maintenance and the next phase of the roadmap simply because it is faster than onboarding a new team from scratch, not because they are locked in.

Thirty days of active post-launch support is included with every build as standard — monitoring for anything that surfaces under real usage, fixing it quickly, and confirming your analytics are actually recording correctly, which is a surprisingly common thing to get wrong at launch. After that window, most clients move onto an ongoing maintenance retainer. Launch is genuinely the beginning of the interesting problems, not the end of the project — real users behave in ways no amount of testing fully predicts.

It scales with the complexity of what is being maintained and the response-time commitment attached to it — a simple marketing site needs far less than a platform with active integrations and daily transactions. What every tier includes regardless of size: uptime monitoring, security patching, and backups that are actually tested by restoring them, not just taken and left untouched on a server somewhere. We would rather quote a retainer that genuinely covers what you need than sell a cheap one that quietly excludes the thing that eventually breaks.

Uptime and error monitoring around the clock, core and plugin updates tested on a staging copy before they ever touch your live production site, security patching applied on a defined schedule, backups we verify by actually restoring them periodically, and a set monthly allowance for small content or code changes. You also get a plain-language monthly summary — not a wall of raw server metrics nobody on your team has time to interpret.

A site-down or checkout-broken issue gets a response within four hours, and we stay actively on it until it is resolved, not just acknowledged. Ordinary requests — a content change, a minor bug — are answered the same working day. These commitments go into the written agreement rather than being left to goodwill, because "we will get to it soon" is not a service level, it is a hope.

We take it offline immediately to stop further damage, restore from a backup we already know is clean, identify exactly how the attacker got in and close that specific hole, then write up what happened and what changed as a result — in plain language, not a jargon-heavy incident report nobody reads. The entry point in these situations is almost always a known vulnerability in something that was overdue an update, which is precisely why the unglamorous, routine maintenance work matters more than it sounds like it should.

Yes. Every case study in our portfolio is a project we actually delivered, named with the client's permission, describing the real challenge, the approach we took, and the measurable result — not a composite or a hypothetical. Where a client has asked to stay unnamed, we say so rather than inventing a name to fill the gap.

Yes — the Case Studies section is the best place to start, filtered by the kind of project closest to yours. If you want something more specific than what is published (a particular industry, a particular type of build), tell us on a discovery call and we will walk you through relevant work directly, including projects that are not yet public.

New case studies go up as projects wrap and the client signs off on what can be shared publicly, typically every few weeks. The blog runs on a slower, more deliberate schedule — we write when we have something specific and useful to say, not on a fixed content calendar, so an article here is closer to field notes than filler.

Practical, decision-focused writing on web and software development, digital transformation, product design, and the business side of technology — the kind of thing we would explain on a discovery call, written down. It is aimed at people evaluating a project or a vendor, not at other developers, so we keep the jargon out and the reasoning in.

The FAQ is the fastest way to rule things in or out — pricing ranges, typical timelines, how we handle security and support — before you commit any time. Once your situation has specifics a general answer cannot cover (an unusual integration, a hard deadline, a particular budget constraint), a discovery call is the more useful next step; most people do both, in that order.