Enterprise Web Development for Large Sites and Portals

§ 01 · scope

What counts as enterprise web work, and what does not

the short answer

Enterprise web development is the design, build and running of a large organization's public web estate, where many editors publish, several business systems feed the pages, and accessibility, privacy and uptime are obligations rather than extras. With us it starts with a free 30-minute call, a scope in writing within 48 hours, and then two weeks of discovery priced separately from the build.

A focused first version of a custom platform typically costs $40,000 to $150,000, and complex enterprise platforms $250,000 to $500,000 or more. The cost section explains what moves a quote inside those ranges.

Four kinds of property sit under the label, and most enterprise briefs combine two or more of them.

Corporate and multi-brand sites: one content system behind several brands, with shared components, so legal pages, cookie consent and tracking change once for every site.
Multi-region and multi-language sites: localized pages marked up with hreflang so Google can show each market its own version, and right-to-left layouts where a language needs them.
Customer, partner and dealer portals: a sign-in where outside users see their own orders, documents, tickets or price lists, read from the CRM or ERP rather than copied into the site.
Web stores and B2B ordering: catalogue, prices, stock and order status taken from the system of record, so the site never sells what the warehouse cannot ship.

Three neighbouring needs have pages of their own. Browser apps used by your own staff, with single sign on and data heavy screens, are covered by our enterprise web application development services. ERP, CRM and HR systems sit under enterprise software development. A site for one small or mid-sized business is custom website development.

§ 02 · which one you need

A business website, an enterprise site and an internal app, side by side

Buyers often arrive unsure which of the three they are commissioning, and the answer changes the team, the budget and the risks. The rows below are our working judgement, not measured benchmarks. The last row says where each one is covered.

How a business website, an enterprise website or platform, and an internal enterprise app differ in users, editors, connections, risk and rules
Question	Business website	Enterprise website or platform	Internal enterprise app
Who uses it	Prospects and customers of one business	The public, customers and partners, often in several markets	Your own staff, signed in through the company directory
Who changes it	One or two people in marketing	Editors in several departments, with brand or legal sign off	Product owners and IT, through planned releases
What it connects to	A contact form, analytics and perhaps a booking tool	CRM, ERP or product data, site search, consent and marketing tools	Systems of record, the identity provider and reporting
What an outage costs	Some missed enquiries	Orders, leads and search traffic in every market at once	A department that cannot do its work
Rules it must meet	A privacy notice and basic consent	Accessibility law, privacy and consent rules in each market, brand rules	Internal security policy, audit and record retention
Where we cover it	Custom website development	This page	Enterprise web applications

§ 03 · requirements

Seven requirements to write into the scope

Put these seven in the scope, whoever you hire. Each one ends with what should exist on launch day, so you can check it rather than take it on trust.

1. Editors who can publish without a developer, but not alone

A large site can have dozens of people changing it. The content system needs roles for writing, reviewing and publishing, an approval step for pages that brand or legal must see, scheduled releases for launches across time zones, a log of who published what, and a history that restores any earlier version of a page.

Model content as fields, such as a product's name, price and spec sheet, so one edit reaches every page that shows it.

On launch day: a written permissions matrix and an editor guide.

2. Integrations with a written contract and a plan for failure

Forms should land in the CRM, prices and stock should come from the ERP or product database, and search should index what editors publish. Each connection needs a documented contract, a test against a staging copy of the other system, and a rule for when that system is down: usually a queue that retries, so a lead or an order is never lost because a partner API was slow.

On launch day: an integration map with every connection, its owner and its failure rule. Our free integration cost calculator estimates the hours per connection.

3. Sign-in that matches who the visitor is

Customers expect email, passkey or social sign-in. Partners and dealers need accounts that see only their own price list or tickets. Editors should use their work accounts from the company directory, so their access ends on the day they leave. Roles belong in the database, not only hidden in the screens, and that is how we enforce them in the platforms we build, with PostgreSQL row-level security.

On launch day: a list of roles and a tested step for removing a user.

4. Speed measured on real visitors, not a lab score

Google's Core Web Vitals set the bar, read at the 75th percentile of page loads: Largest Contentful Paint, the main content appearing, within 2.5 seconds; Interaction to Next Paint, the reply to a tap or click, at or under 200 milliseconds; and Cumulative Layout Shift no higher than 0.1, as web.dev sets out.

A public site has one advantage here: Chrome's field data covers pages that are publicly discoverable and visited often enough, so a vendor can show real numbers. On a large site, tag managers, chat and consent scripts added after launch often undo a fast build, so check the budget on every release, not once.

On launch day: field data for the main templates, which you can read yourself in our free Core Web Vitals checker.

5. Accessibility treated as a release condition

Build to WCAG 2.2 at level AA, the current W3C standard, and test with a keyboard and a screen reader as well as scanners, because a scanner cannot judge every success criterion. If you sell into the EU, the European Commission lists e-commerce and banking among the services the European Accessibility Act covers.

On launch day: an audit against WCAG 2.2 AA with every open issue listed, an accessibility statement and a way to report a barrier. The free color contrast checker on this site settles one criterion in seconds.

6. Security, privacy and consent built in from the first release

Treat the 2025 edition of the OWASP Top 10 as the minimum list of web risks to test against. Keep API keys on the server, send security headers such as a content security policy, and load analytics and advertising tags only after consent where a market's law requires it. Patch dependencies on a schedule after launch, since an unpatched site grows less safe with every published vulnerability.

On launch day: a header report, a record of how consent is collected, and a named owner for patching. Our free HTTP headers checker audits any site's headers.

7. Search traffic that survives the rebuild

An established site already earns search traffic, and a rebuild that changes URLs can lose it. Google's guide to site moves asks for a mapping from every old URL to its new one, served as permanent redirects. Google also says its AI Overviews and AI Mode need no special files or markup, so crawlable, well structured pages serve both.

On launch day: a redirect map with no chains and hreflang for each market, both testable with our free redirect chain checker and hreflang checker.

§ 04 · stack

Technology choices you can staff after launch

Every choice below is one a newly hired engineer will already know, because a platform you cannot staff is a platform you cannot leave. On every build our CTO, Divyansh Singh, sets the architecture, and each significant decision is written up as an architecture decision record, so the next team inherits the reasons along with the code.

The layers of an enterprise web platform, what we usually build each one with, and why that choice suits a large site
Layer	Our usual choice	Why it suits a large site
Pages and templates	Next.js and React; Laravel or Angular where the current platform already uses them	Pages can be built ahead of time and cached, with live data only where it is needed
Content editing	WordPress, Webflow or a headless content system, settled in discovery	Editors get a tool that fits how many of them publish and how often, and the choice is recorded with its reasons
Accounts, roles and records	PostgreSQL hosted on Supabase, with row-level security	The database itself decides who reads which record, and Supabase encrypts data at rest with AES-256
Integrations and background tasks	Node.js, with Cloudflare Workers at the network edge	This site's own booking and chat APIs run on Workers, close to each visitor
Code and hosting	Repositories and cloud accounts in your name, on your billing, from the first sprint	Our engineers join as collaborators whose access you can revoke at any time, so changing teams needs nothing handed back by us

The content editor is the one layer worth deciding late. Whether editors stay in WordPress, move to Webflow or write into a headless system depends on who edits, how often, and how many sites share the same content, and discovery is where those answers arrive. Anything written for your platform is assigned to you once the final invoice is paid; what stays with us is tooling that existed before your project or was made for general reuse.

§ 05 · proof

Work we can show, with each client's permission

Both clients gave permission for their projects to appear here. Neither has published a results figure, so none is given: each card says what the platform does and which parts of an enterprise brief it carries.

clinics and hospitals · 2026

Planivo, a bilingual platform for teams across several sites

We built all of Planivo: the signed-in platform and its public website. It plans monthly shift rosters for clinics and hospitals, sends each vacation request up three levels for approval with a warning when two staff of the same speciality would be away together, and runs tasks, training sessions with attendance, certification expiry reminders and on-duty display screens.

The enterprise part is the structure around those features: one organization spanning headquarters, branches and teams, each organization's data kept within its own boundary, six roles that each see only their own slice, an audit history of changes, and an interface in English and Arabic that switches the whole layout to right-to-left.

planivo.me

web to print, South Africa · 2026

SpeedyPrint, a print store with its own design editor

A web store where customers design labels, race numbers, stamps and trophies in the browser, including CSV jobs in which each item prints its own name or number. Every order produces proofs and production files and keeps a status history, and checkout runs through PayFast and its payment webhooks, with transactional email.

Behind the store, staff manage orders, products, templates and users in an admin panel with three roles: customer, admin and production staff. Its stack is Next.js 15, React, TypeScript and Supabase.

Planivo's public home page, with a language switch for English and Arabic, a sign-in button, and the four headline features: monthly shift planning, three-level vacation approvals, speciality conflict checks and on-duty screens — Planivo's public site as it looked in early October 2026, part of what we built. The globe at the top right switches the interface between English and Arabic.

The live chat on this site is our own build as well: its APIs run on Cloudflare Workers, its conversations are stored in PostgreSQL on Supabase, and our team answers them inside our own CRM, which carries an AI copilot we also built.

For reviews across all of our work, our Clutch profile shows 5.0 from 66 verified reviews (checked 13 October 2026). Further client work can be walked through on a call after both sides sign a one-page mutual NDA.

§ 06 · process

Six steps from a first call to a live site

A free 30-minute call. Calls are set at least five days out, which gives us time to study the live site, any code you share and your documents before we talk. When the work fits, a scope in writing and a quote arrive within 48 hours.
A two-week discovery, priced separately. Workshops with the site's editors and users, a map of every system it touches, a risk register and the first decision records, plus a threat model, a diagram of how data moves and a check on where keys and passwords are kept. New York clients can hold the kickoff in person. You leave with a fixed price, or with the name of an existing product that would serve you better.
Design and architecture. Content model, templates and user roles are settled before code is written, and the architecture needs our CTO's sign-off.
Sprints of one to two weeks. Each week closes with a recorded demo of working pages and a short note on what was finished and what moved. A week that ends without that demo is not invoiced.
Testing and launch. Every build passes our QA team before it reaches you, a CI pipeline runs the automated tests, and rollback is rehearsed ahead of the first release. Larger platforms go live one part at a time.
Support or handover. Keep a named team on a monthly retainer to run and improve the platform, or take the handover pack, with architecture notes, runbooks and a walkthrough, to whoever runs it next.

What a website migration has to produce, whoever runs it

An inventory of every live URL, with its traffic and its new address.
A permanent redirect for each old URL that has a new home, tested for chains and loops before launch.
A content inventory that names an owner for each section, so nothing moves without a reviewer.
Analytics and consent checked to record the same events after the switch as before it.
A short editing freeze before the switch, and a launch week spent watching error logs and Search Console.

§ 07 · cost

Price ranges, timelines and what moves them

We price after discovery, not from a list, and our custom software ranges apply here. A focused first version typically costs $40,000 to $150,000, while complex enterprise platforms can cost $250,000 to $500,000 or more, depending on scope, integrations, security and data migration. On a fixed bid, a first version usually takes 8 to 12 weeks and a production platform 16 to 28.

Five things move an enterprise web quote the most:

Templates, sites and languages: each distinct template is designed, built and tested once, and each language adds translation and review.
Integrations: every system the site reads from or writes to needs its own contract, tests and failure rule.
Content to migrate: moving and checking thousands of old pages can cost more than rewriting fewer, better ones.
Accessibility and compliance: the audit, the fixes, and any legacy documents that must be made accessible too.
Traffic and uptime: the target decides the caching, the monitoring and the hours of support cover.

Upkeep carries on after launch: GoodFirms' 2026 survey puts it at 10 to 20 percent of the build cost every year. For a smaller site or a single portal, our website and web portal cost calculator turns seven answers into a build range and a timeline.

There are three ways to contract the work: a fixed bid against the scope discovery writes; a dedicated team billed monthly, with a lead, engineers and QA, for a longer roadmap; or a retainer after launch, where the smallest team we staff is one senior engineer with one designer. Work outside a fixed scope starts only after a written change request, with its price and new date, is agreed.

§ 08 · comparing vendors

What to ask a web agency, and what a weak answer sounds like

Send the same six questions to every firm on your shortlist and read the replies side by side. Each one targets a problem that tends to surface only after a public site is live, when it costs the most to fix.

Six questions to put to any enterprise web vendor, why each matters on a public site, and the kind of answer that should worry you
Ask	Why it matters on a public site	A weak answer sounds like
In whose name are the domain, DNS, hosting and content system licence?	A domain held in an agency's account can stall a launch, a renewal or a move to another team.	"We look after all of that for you."
Which public site that you run today can we check for field Core Web Vitals?	A lab score on a quiet staging build says little about real visitors with every tag loaded.	A Lighthouse screenshot taken on staging.
How will every old URL be mapped and redirected, and how will you test for chains?	Search traffic earned over years can fall away when old addresses stop resolving.	"We will redirect the important pages."
What happens to a form or an order while the CRM or ERP is down?	Leads and orders arrive at all hours, including during the other system's maintenance window.	"That system is very reliable."
How is an editor's access removed on the day they leave?	A former employee who can still publish is a brand and legal risk.	"Tell us and we will delete the account."
Who keeps third-party tags inside the speed budget after launch?	Marketing, chat and consent scripts are the usual reason a fast site slows down months later.	"We optimize everything before launch."

Our own answers to three of them are on this page already: ownership in the stack table, redirects in the migration list, and failure rules under the second requirement.

When another firm is the better choice

Need every engineer on US soil? Then we are the wrong firm. Our headquarters is in New York, home to leadership and our US account directors, and a team there replies within the same working day, 9 AM to 6 PM Eastern. The engineers themselves work from Delhi and Lucknow, on hours that overlap the Eastern working day.

If your organization has standardized on a licensed digital experience platform such as Adobe Experience Manager or Sitecore, look for a partner certified on that product; this page claims no such certification. And if the program needs dozens of engineers on day one, a large consultancy is built for that and we are not.

If one editor runs a small marketing site, an enterprise build is more than you need, and our custom website development service fits that brief. Our MSA, IP terms and support options are set out on our custom software development company page.

§ 09 · questions

Enterprise web questions, answered briefly

What is enterprise web development?

It is the work of designing, building and running a large organization's web estate: public sites across brands and regions, customer and partner portals, and web stores. The tools are often the same as for a small business site. The difference is scale: editors with approval steps, several business systems feeding the pages, accessibility and privacy duties in each market, and traffic that cannot be interrupted.

How much does enterprise web development cost?

With us, expect $40,000 to $150,000 for a focused first version and $250,000 to $500,000 or more for a complex enterprise platform. The number of templates and languages, the integrations, the content to migrate, the accessibility work and the uptime target decide where yours lands, and the fixed price is set after a two-week discovery sprint. The cost section explains each factor.

How long does it take to build an enterprise website?

After two weeks of discovery, a fixed-bid first version usually takes 8 to 12 weeks and a production platform 16 to 28. Migrating a large existing site adds time for the URL inventory, the redirects and the content review, which is why the launch date goes into the written scope instead of being promised on the first call.

How is an enterprise website different from a small business website?

Mostly in who edits it, what it connects to and what an hour offline costs. A small business site has one or two editors and a contact form. An enterprise site has editors in several departments with sign-off steps, data from a CRM or ERP, legal duties in more than one market, and enough traffic that any outage is felt. The comparison table sets the two side by side, with internal apps as a third.

Which content management system suits an enterprise website?

There is no single right one. WordPress is the most common: W3Techs finds it on 58.4 percent of websites whose content system it can identify (checked 17 October 2026). A headless system suits content shared across several sites and apps, and a hosted builder such as Webflow suits a marketing team that wants to publish alone. Choose on the number of editors, the approval steps and the systems that must feed it.

Do you take over existing enterprise sites, or only build new ones?

Both. When a live site has to keep running while it is rebuilt, discovery reads its code and content first and writes down what it found. A large platform is then replaced in phases, one part at a time, with a tested rollback in place, while the old one keeps serving visitors.

What security measures does an enterprise website need?

At a minimum: testing against the OWASP Top 10, TLS on every page, secrets kept on the server, security headers including a content security policy, roles checked by the database itself, a log of who changed what, and dependency patching on a schedule. If a vendor claims SOC 2 or ISO 27001, ask who audited them and when the report was issued. This page claims neither.

Is AI replacing web devs?

Not on enterprise work. AI tools are now routine: 84 percent of respondents to Stack Overflow's 2025 Developer Survey use them or plan to. They speed up writing code. They do not decide which systems a site connects to, who signs off the accessibility audit, or what happens when a payment webhook fails in launch week, and on a large site those decisions carry the risk.

Last reviewed 17 October 2026.

§ 10 · next step

Bring the current site and the systems behind it

Tell us which sites, portals or stores are in scope, which systems feed them and which markets they serve. After a 30-minute call, a written scope and a quote follow within 48 hours, and the build gets a fixed price once discovery closes. Book a call with a web engineer.

Why work with Digital Heroes

115 people in New York, Delhi, Lucknow, London and Sydney, shipping ecommerce, web, software and mobile work for founder-led brands. Senior engineers only, no account-manager relay, and the same team from kickoff to launch.

Shopify Select Partner, as listed in the Shopify Partner Directory
Tier 1 registered supplier on the United Nations Global Marketplace, which requires audited company documentation
Top Rated Plus on Upwork, the bracket for the top 3% of talent by client outcomes
397 public five-star-weighted reviews across four Fiverr gigs, from clients in 36 countries
DUNS verified business, No. 650878346, so procurement can check us before signing
Listed by Clutch in Top 1000 Global B2B Companies and Top Web Designers 2024
Verified profiles on GoodFirms, DesignRush, Digital.com, AppFutura and TopDevelopers
2,000+ brands built across 40+ countries, with $50M+ in client revenue scaled

Book a call

More from Divyansh.

Chief Technology Officer · Lucknow · 50 posts on the site

post

Enterprise Web Development