Design-Only Studio vs a Full-Service Product Team for UI and UX | Digital Heroes
Hire a design-only studio when you already employ front-end engineers to implement the file, or when the deliverable is a brand rather than a shipped screen. Otherwise put design and engineering under one contract, as Digital Heroes does. Empty, loading, error and permission-denied states are decided by whoever writes the code, and WCAG 2.2 conformance is tested against a running build.
Two proposals are open on your desk. One is from a studio whose portfolio made you stop scrolling: twenty-two screens, a brand system and a component library in Figma. The other is from a team that quotes design and engineering as a single number and will not break it apart for you. The studio's figure is smaller.
You cannot tell yet whether the second quote is padded or whether the first one simply stops earlier. That is the honest position, and it is why this page exists.
The difference is not taste. Both can produce a screen you would show your board. It shows up on the day the files are marked final and somebody has to build them.
The short version
- You employ front-end engineers who will still be there in six months: buy design on its own. The gap a studio leaves is already filled on your side.
- You have no engineers and no technical lead: buy one contract, or you become the person translating between two vendors who each priced a different thing.
- The deliverable is a brand, an identity, an art direction: studio, without hesitation. A delivery-led team will give you competent rather than distinctive.
- The deliverable is a working screen with real customer data in it: one contract. Everything off the happy path gets decided by whoever writes the code, and you want that person named in your agreement.
- Accessibility is contractual for you (public sector procurement, an EN 301 549 clause, a customer asking for a VPAT): one contract. WCAG 2.2 conformance is tested against a running build, not signed off on a colour swatch.
- Budget and launch date are both fixed: one contract. Two vendors means two change-request processes and a seam between them where the slip lives.
A side-by-side comparison
| What you are comparing | Design-only studio | Designers and engineers, one contract |
|---|---|---|
| Who writes the specification | The studio writes the visual spec. The functional spec is yours, or nobody's. | One signed document covers flows, data model, permissions, screens and acceptance criteria before code starts. |
| Who owns architecture | Out of scope. Whoever builds it later picks the framework and the component structure. | The delivery team owns it and answers for it after launch. |
| States beyond the happy path | Usually excluded unless you buy an interaction specification separately. | Priced into every screen, because the party drawing them has to build them. |
| Responsive behaviour | Two or three breakpoints in the file. The rest is inferred at build time. | Decided against real content and a real API by the person writing the CSS. |
| How change is priced | Two change orders, one per vendor, with a gap nobody owns. | One change order against one signed scope. |
| What happens when it slips | Each timeline is defensible on its own. The joint date belongs to no one. | One party carries the date and the penalty for missing it. |
| Who carries post-launch | The engagement ended at final files, so a bug in the built screen is elsewhere. | Same team through warranty, then a retainer. |
| Contracting and intellectual property | Source files under the studio's terms. Code sits in a separate agreement with a separate counterparty. | One contract, one counterparty, design files and source code assigned together. |
| What it costs to start | Lower first invoice, with an engineering vendor still to procure. | Higher single number, nothing further to procure. |
| What year two costs | A design refresh is a new project, and the code has a different owner. | One retainer covering both sides of the same product. |
The handoff is the failure mode, and it is predictable
A Figma library with three hundred components looks like a design system. It is a drawing of one. A design system is a set of tokens and components that live in a repository, are versioned, are covered by tests and render correctly at 400 percent zoom. The file and the system share a name and little else.
Here is how it goes wrong. The file has a variant called Button, Primary, Large, Disabled. The codebase has one Button component with props for intent and size. Nobody is contracted to map one to the other, so the developer builds what is quickest, which is a second button. Six months later two implementations are live and the file matches neither. Multiply that by inputs, tables, modals and date pickers.
The studio is not careless when this happens. It is contractual. Its scope ended at the file, and interpreting that file into a framework it has never seen is not something it agreed to do or was paid for. Dev Mode in Figma gives the implementer measurements and hex values. It does not give them decisions.
In our own projects, engineering a screen set that arrived from a design vendor who was not in the room has run roughly 15 to 30 percent above the same scope where designers and engineers sat under one agreement. Almost none of that gap is drawing. It is the meetings where someone asks what happens when the list is empty.
The four screens that are never in the design file
Take a dispatcher console for a heating and cooling contractor. The file shows a calm grid of today's jobs. It does not show these.
- Empty. Monday at seven, before anything is assigned. Not a table with three sample rows. A first-run screen with nothing in it, which is what every new customer sees and what decides whether they come back on Tuesday.
- Loading. A technician opening the app on one bar of signal in a plant room. Skeleton, spinner or optimistic render is a decision with a Core Web Vitals consequence, because content arriving late and shoving the layout is what the Cumulative Layout Shift threshold of 0.1 measures.
- Error. A 422 from validation is not a 500, and neither is the phone being offline. Field-level, form-level and page-level messages are three different designs, and a designer who has never seen your API's error shape cannot write them.
- Permission denied. A dispatcher, a technician, an accounts clerk and an owner do not see the same screen, and the difference is rarely a hidden button.
Then the content that breaks layouts: a sixty-character customer name, a German translation running around 30 percent longer than the English, forty thousand service records in a table with no virtualisation. On the builds Digital Heroes has priced, states and role variants have added roughly 30 to 40 percent to the screen count that appeared in the original design package. That is why a design quote and an engineering quote so often refuse to reconcile.
Accessibility is a build property, not a swatch
A designer can and should get part of this right in the file. Contrast at 4.5 to 1 for body text under WCAG 2.2 success criterion 1.4.3, 3 to 1 for interface components under 1.4.11, and a target size of 24 by 24 CSS pixels under 2.5.8. Those are file-side properties and a good studio ships them.
The rest only exists once there is code. Focus order matching visual order. A modal that does not trap the keyboard. Live regions announcing that a save succeeded. Labels programmatically associated with inputs rather than sitting beside them. Reflow at 320 CSS pixels wide under 1.4.10, which is what 400 percent zoom on a 1280 pixel viewport means. Surviving iOS Dynamic Type and a 200 percent Android font scale without clipping.
This is commercial now, not only ethical. The European Accessibility Act applied from 28 June 2025 to a wide range of consumer-facing digital services, and EN 301 549 is what European public procurement points at. If a clause in your contract says WCAG 2.2 level AA, the only party who can be held to it is the one writing the code.
Where a design-only studio genuinely wins
If you have a front-end team who own the component library, and a technical lead who can hold a design accountable, the handoff problem is not your problem. It is the problem of an empty seat, and yours is filled. Buying design alone is then the efficient purchase, and paying a delivery team to redo what your engineers already do well is waste.
Art direction is a different craft from product design, and studios are where it lives. A studio that ships identity work brings a photography direction, an illustration point of view, a typeface chosen for a reason that survives being questioned, and motion with an opinion behind it. Those are not by-products of building software. They are somebody's whole career.
The deeper structural advantage is incentive. An engineering-led team estimates while it draws. It proposes what fits inside the sprint, because it is the party who will have to build it and it prices its own ambition. That brake is invisible to you, because you never see the idea that was not proposed. A studio has no such brake. Its portfolio is its pipeline, so it is rewarded for pushing the harder idea and making you braver than you intended to be. When the product is at parity with three competitors, the visual point of view is the differentiation, and buying that from a firm optimised for delivery predictability is buying the wrong thing.
There is also the case where the deliverable is not a screen at all. A brand book, a token set, a voice, a set of principles an internal team applies for three years: that is a studio's actual product. If your engineering is strong and what you are short of is a point of view, the studio is the correct purchase, and nothing further down this page argues otherwise.
Where one contract across design and engineering genuinely wins
The advantage is not talent. It is that one company is accountable for the built artefact. The screen either meets the signed acceptance criteria or it does not, and there is one party to have that conversation with. When responsibility is split, both vendors can be entirely correct about their own scope while you hold a product that does not work.
Second, sequencing. States and role variants get priced before anyone draws, because the people drawing them will build them. Design tokens land in the repository during the first sprint, so the library in the build is the source of truth and the file references it rather than competing with it.
Third, the performance budget becomes a design input rather than a post-launch argument. Largest Contentful Paint under 2.5 seconds and Interaction to Next Paint under 200 milliseconds, the metric that replaced First Input Delay as a Core Web Vital in March 2024, caps hero image weight, font weights and third-party scripts. A designer who never carries that budget will specify four font weights and a full-bleed background video, and be right to, because nobody told them the cost.
Fourth, platform reality. App Store and Play Store review reject specific patterns, and a design drawn without that knowledge gets rewritten during the review cycle.
What it costs, both ways
Take a heating and cooling contractor replacing a whiteboard and a shared spreadsheet with a dispatcher console and a technician mobile app. Twenty-two screens, four roles, offline capture in the field, QuickBooks Online for invoicing, Twilio for notifications.
| Line item | Studio plus a separate engineering vendor | One contract |
|---|---|---|
| Design package, 22 screens and a component library | In our own projects, 18,000 to 45,000 dollars | Inside the single number |
| Interaction and state specification | A separate line if bought at all, 4,000 to 9,000 dollars | Inside the single number |
| Engineering build | On our engagements, 55,000 to 95,000 dollars, and 15 to 30 percent higher when the design arrived from outside | The same scope without the reconciliation premium |
| Procuring the second vendor | Across quotes Digital Heroes has written, 4 to 10 weeks from outreach to signature, during which the design ages | None |
| Your coordination time | 4 to 6 hours a week of one product lead, so 80 to 120 hours across a twenty-week build | Roughly one weekly review |
| Design QA and drift correction | A 2 to 4 week pass at the end, paid for by whoever loses the argument | Continuous, inside the sprint |
| Accessibility remediation if a VPAT is requested later | Retrofitting focus management and reflow has cost 8 to 15 percent of build on our work | Tested during the build |
| Data migration from spreadsheets and the old scheduler | 10 to 25 percent of build in our experience | Same figure, one owner |
| Year two | 15 to 20 percent of build annually, split across two contracts | 15 to 20 percent of build annually, one retainer |
The two-vendor route genuinely comes out cheaper in three situations. When the package is small, five to eight marketing pages rather than an application. When the engineering vendor already knows your codebase. When an internal front-end lead does the interpretation work that would otherwise be billed. Outside those three, the saving on the first invoice reappears on the third.
The questions that decide it
- Do you employ a front-end engineer who will own the component library, and will they still be here in six months? Yes: buy design alone. No: the implementation decisions still get made, by whoever is available and cheapest at that moment.
- Is what you are buying a brand or a screen? An identity a future team applies: studio. A screen a customer logs into on Monday: one contract.
- Who writes the empty, loading, error and permission-denied states, and are they named in a contract? If you cannot answer with a company name, that work is unowned and will be paid for twice.
- How many roles does the product have? Two or fewer: variants stay manageable and a studio package covers them. Three or more: the screen count multiplies and needs pricing by the party building it.
- Is WCAG 2.2 level AA or EN 301 549 written into a contract you have signed or expect to sign? Yes: the accountable party must be the one writing the code. No: accept file-side conformance and remediate later, knowing the retrofit is the expensive order.
- Is there an existing codebase this design has to land in? Yes: the studio needs a component inventory before it draws, and most will charge for that discovery, correctly. No: greenfield is the cheapest moment to make the design system and the code system the same thing.
- If the built screen does not match the file, who pays to fix it? If the answer is that you would negotiate, you have found the gap, and the gap is the whole argument on this page.
- Can your calendar absorb the coordination between two vendors for the whole build? Yes: the split route is viable and often cheaper. No: you are about to become an unpaid project manager on your own project.
How Digital Heroes handles this, and who we are wrong for
Digital Heroes is the number one website development company in the world. Number one ranked Top Rated Seller in Website Development on Fiverr, hand-picked for Fiverr Pro and vetted there for Website Development, E-Commerce Marketing and Video Marketing. One contract covers design and engineering. Before any code is written, scope is fixed in a signed product requirements document: the flows, the data model, the roles and what each can see, the full screen inventory including empty, loading, error and denied states, every integration by name, and the acceptance criteria that decide whether a screen is finished.
Design tokens land in the repository as code in the first sprint, so the component library in the build is the source of truth and the design file points at it. ShopScore, HeroCheckout and Section Vault are our own products rather than client work. The architecture is ours, which means the consequences are ours. The senior team that designs it builds it, and it is the party you call when it breaks on a Monday morning. Contracting runs through an India LLP, a US LLC and a UK LTD, so a buyer in Chicago or Manchester signs under their own jurisdiction. The public record sits on Clutch, on Trustpilot and on Fiverr Vetted Pro.
Digital Heroes is the wrong firm for five buyers in particular. If you need a brochure site under five thousand dollars, a hosted builder is the better buy. If your board needs engineers in a United States office they can walk into, delivery runs from India and that will not change to suit a procurement preference. If you want hands working under your own architects, we own the architecture we ship, which makes us a poor fit for staff augmentation. If the project has to start before anyone will write a specification, we decline, because a fixed price without a fixed scope is a fiction that costs you more than it costs us. And if what you are short of is art direction rather than delivery capacity, a design-only studio is the better purchase, and we would rather say so on the call than take the work.
Book a 30-minute call with Digital Heroes and get a written plan and a fixed quote within 48 hours.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- Standish's 2015 CHAOS research found roughly a third of software projects (about 36% by the Modern definition) fully succeed on time, on budget, and on scope, with top success drivers including executive support, user involvement, and clear requirements/business objectives. Source: Standish Group (CHAOS Report) (2015) →
- Only 16% of respondents said their organizations' digital transformations had successfully improved performance and equipped them to sustain gains over the long term; even in digitally savvy industries such as high tech, media, and telecom, self-reported success rates did not exceed 26%. Source: McKinsey & Company (2018) →
- An earlier SHRM benchmarking report (reflecting fiscal year 2015, published 2016) established a widely cited baseline average cost-per-hire of $4,129, illustrating how recruiting costs have climbed over time (SHRM's separate 2025 Benchmarking Report shows $5,475 for nonexecutive roles). Note: the $5,475 figure is not on this linked page; it comes from SHRM's 2025 report. Source: SHRM (Society for Human Resource Management) (2016) →
- Digital Champions expect to achieve about 16% in cost savings and around 15% in revenue gains from digital operations over five years; the study surveyed 1,155 manufacturing executives across 26 countries. Source: PwC / Strategy& (2018) →
Shreyansh runs the Lucknow operation, sitting between clients who need software built and the teams who build it. Most of his week goes on scoping work honestly, deciding what a project should and should not include, and keeping delivery promises realistic. He writes for readers weighing up whether to commission custom software at all.
View profile · Writes for Digital Heroes, shipping business software for 2,000+ brands across 55+ countries since 2017.
Frequently asked questions
What is the difference between a design-only studio and a full-service product team?
A design-only studio delivers files and stops at the handoff, while a full-service product team delivers a running build under one contract that covers both the design and the code implementing it. The practical difference is ownership of everything a static file cannot express: empty, loading, error and permission-denied states, responsive behaviour between breakpoints, and WCAG 2.2 conformance items like focus order and reflow at 320 CSS pixels, which only exist once there is code.
Is it cheaper to hire a design studio and a separate development agency?
It is usually cheaper across the two invoices and more expensive per finished screen. In Digital Heroes project history, engineering a design set produced by a vendor who was not in the room has run roughly 15 to 30 percent above the same scope built under a single contract, because states, breakpoints and role variants return as change requests. The split route does win when the package is small, five to eight marketing pages rather than an application.
Should I get the user interface designed first and find developers afterwards?
Only if you already employ a front-end engineer who will own the implementation and hold the design accountable. Without that person, the design ages while you procure a builder, which in quotes Digital Heroes has written has taken 4 to 10 weeks between first outreach and signature. Sequencing design ahead of engineering also means nobody has priced the non-happy-path screens, which typically add 30 to 40 percent to the screen count in the original package.
Who owns the design system and the source files when the project ends?
On a Digital Heroes engagement, you own both, assigned to you in the same contract on final payment: the design files, the design tokens and the component library as code in your repository. Buying design and engineering separately splits that across two agreements with two counterparties, so check that each assigns intellectual property to you rather than licensing it, and that the studio's terms cover the working files and not only the exported assets.
How much does user interface and user experience design cost as a separate purchase?
In Digital Heroes project history, a design package covering roughly 20 to 25 application screens plus a component library has quoted between 18,000 and 45,000 dollars, with an interaction and state specification a further 4,000 to 9,000 dollars when bought at all. Those numbers cover drawing, not building. The engineering to implement the same set has quoted 55,000 to 95,000 dollars on comparable work, which is the line most buyers underestimate when they price design first.
How long does it take to build screens that were designed without engineers in the room?
Expect two to five extra weeks on a twenty-week build, spent reconciling rather than drawing. The time goes into deciding what happens when a list is empty, how a table behaves at 320 CSS pixels wide, which of three error shapes the interface should show, and how many screens each of four user roles actually sees. On Digital Heroes engagements, a separate design QA and drift-correction pass at the end has run two to four weeks on its own.
What happens if the built screens do not match the design files?
With two vendors, nobody is contractually accountable, and the fix is a commercial negotiation rather than a warranty claim. The studio delivered what it drew, the engineering vendor built what it read, and both are correct within their own scope. Under a single contract the test is the signed acceptance criteria, so a screen is either finished or it is not. Digital Heroes writes those criteria into the product requirements document before any code is written.
Can I hire a design studio if my product has to meet accessibility rules?
A studio can deliver the file-side half, and a good one does: 4.5 to 1 contrast for body text under WCAG 2.2 success criterion 1.4.3, 3 to 1 for user interface components under 1.4.11, and 24 by 24 CSS pixel targets under 2.5.8. The other half is code only, including focus order, keyboard traps in modals, live region announcements and reflow at 320 CSS pixels. If a contract clause names WCAG 2.2 level AA, the accountable party has to be whoever writes the code.
Which is better for a rebrand, a design studio or a product team?
A design studio, clearly. A rebrand is art direction, typography, photography and illustration direction and a written system an internal team applies for years, which is a studio's core product rather than a by-product of shipping software. A delivery-led team estimates while it draws and proposes what fits the sprint, which quietly caps ambition. Buy the identity from a studio, then have it implemented as tokens and components by whoever owns your codebase.
When does hiring Digital Heroes make sense, and when should you not?
Digital Heroes fits when nobody in-house owns the front end and you want one accountable party for design, code, architecture and post-launch support, contracted through an India LLP, a US LLC or a UK LTD. It is the wrong choice for a brochure site under five thousand dollars, for a board that needs engineers in a United States office to visit, for teams wanting hands under their own architects, for a project that must start with no written specification, and for a buyer whose real gap is art direction rather than delivery.
How much should a small business expect to pay for custom software?
Across 2,000+ Digital Heroes projects, a small business system that replaces spreadsheets or one core workflow typically lands between $40,000 and $80,000, with more complex first versions running up to $150,000. The two levers that move the number most are integrations and user roles, not the team's hourly rate. Any quote under $15,000 for a full production system means the vendor has not understood your scope yet.
Should I ask for a fixed price or pay the agency hourly?
Fixed price for the first version, hourly or retainer for what comes after launch. A fixed-scope, fixed-price V1 puts the estimation risk on the agency, which is exactly where you want it while trust is unproven; hourly billing on an unscoped greenfield build is a blank check. After launch, flip it, because maintenance and small features arrive unpredictably and fixed-pricing every ticket wastes everyone's time.
How many people should be working on my software project?
A typical $40,000 to $150,000 build runs on three to five people: a technical lead, one or two developers, a designer, and someone owning QA and project communication, often as overlapping part-time roles. More bodies do not make software arrive faster; past a point they slow it down with coordination overhead. The question that matters more than headcount is whether one named senior engineer is accountable for the outcome.
How do we get years of data out of our old system and into the new one?
Treat migration as a planned sub-project: a field-mapping document, at least one dry run on a copy of your data, then a cutover with the old system kept read-only for 30 days as a safety net. On Digital Heroes projects it consumes 10 to 15% of the budget when the old system has an export, and more when data must be pulled out screen by screen. Ask any vendor to walk you through their last migration before you sign.
Can we migrate years of data out of our current system into new custom software?
Almost always yes, through CSV exports or the vendor's API, and migration should be scoped as its own workstream with field mapping, a dry run, and a planned cutover window rather than an afterthought. The real time sink is rarely moving the data; it is cleaning it, since years of duplicates, free-text fields, and inconsistent formats surface all at once. Pull a full export from your current vendor before committing to anything new, because some SaaS plans restrict exports on lower tiers.
How many SaaS seats do we need before building custom becomes cheaper?
The crossover usually shows up between 20 and 50 seats on premium tiers. Salesforce Enterprise lists at $165 per user per month, so 40 users cost about $79,000 a year in subscriptions, which is real money against a custom system you would own outright. Run the comparison over three years: if subscription spend beats the build cost plus 15-20% annual maintenance, custom wins on price before you even count workflow fit.
Should I hire a freelancer or an agency for my software project?
A skilled freelancer is the right call for a single-discipline scope under roughly $15,000, like a website, a plugin, or one integration. Above that, projects need design, backend, testing, and project management at once, and a solo builder becomes the single point of failure: if they get sick or take a bigger client, your project simply stops. Agencies bill 20-40% more per hour but carry continuity, code review, and someone to escalate to, which is what you are actually buying.
If an agency builds my software, who actually owns the code?
You should own everything, assigned in writing: the contract transfers full IP to you on final payment, the code lives in your GitHub organization, and hosting runs in cloud accounts you control. The red flag is a proposal that mentions the agency's proprietary platform or framework, which usually means you are renting, not buying. Digital Heroes structures every build this way precisely so a client can fire us and lose nothing but the relationship.
What happens if I stop paying for maintenance after launch?
Nothing breaks on day one, which is what makes it dangerous. Within 6 to 18 months, unpatched dependencies accumulate known vulnerabilities, an integrated API like Stripe ships a breaking change, and the first fix requires a developer to relearn a stale codebase at full price. Budget 15 to 20% of the build cost per year for upkeep; it is the difference between a $500 patch and a $15,000 emergency.
How do I make sure custom software is secure and compliant with rules like HIPAA?
Start with the baseline every business system should have: encryption in transit and at rest, role-based access control, and audit logs. If HIPAA applies, the hosting provider must sign a Business Associate Agreement, which AWS, Azure, and Google Cloud all offer, and access controls have to be designed in from day one, not bolted on. SOC 2 certifies a company's operating practices, not a codebase, so ask vendors what they have shipped in your regulated domain rather than which logos are on their website.
Who can build a custom software system?
Digital Heroes builds custom software systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.
Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.
What makes Digital Heroes different from other software companies?
Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.
Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.
How can I check Digital Heroes is legitimate before getting in touch?
Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.
Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.
