Nobody searches for enterprise web development for fun. Usually the word arrived from somewhere else first. A large customer sent over a security questionnaire before they’d sign, an investor’s diligence list asked how your web application handles access and backups, a stakeholder pasted it into an RFP template, or a vendor used it in their own pitch. Now you’re holding a requirement with a big word on it, and it isn’t obvious what that word is asking of whoever builds or maintains the thing.

Page one of the search results won’t settle it for you, because most of what ranks there treats “enterprise” as a claim about the vendor. What you actually need is a way to turn the word into things you can check, so that’s what this piece tries to give you: what the label usually sells as, what it has to mean in practice, and a short list you can take into your next vendor call or your own requirements doc.

We read the pages ranking for this search while researching this one, and most of them define enterprise by size. DICEUS leads with 250 full-time tech professionals, nine global offices, and partner badges from Google Cloud, Oracle, and Microsoft. Its process is a four-stage outline of business analysis, design and development, deployment, and support, which describes nearly every software project ever run, and it lists Fixed Price, Time and Materials, and Dedicated Team engagement models without saying what any of them looks like in practice. Security and GDPR get a mention in passing, with no process attached.

Dinarys runs the same play with different numbers: 98+ projects, 7+ years, a long technology list that covers PHP through Kubernetes and Kafka, a “100% satisfaction guarantee,” and compliance badges, but beyond a generic line about ongoing maintenance and support, it says nothing about who stays on your project after launch. The Superside piece in the same results goes a different way and leans on statistics, like the claim that 75% of credibility comes down to design, while leaving out governance, compliance, and integration work, which are the parts that actually change when a site gets bigger.

The one result worth crediting is FDG Web, a US-only shop in Arlington, Washington, with two decades behind it and no outsourcing. They sell enterprise work on HIPAA, SOC 2, and GDPR competence and name real clients such as Astound Broadband, which is more useful than a headcount. Even so, “we don’t outsource” is still a statement about the vendor, and it leaves you to work out what you should be testing for.

When a customer or an investor says your web work needs to be enterprise-grade, the question underneath is whether a specific set of things is true about the system and about the people responsible for it, and those things can be checked on a three-person team as easily as on a three-hundred-person one.

The listicle ranking enterprise web development companies on the same page actually names reasonable criteria: portfolio depth, how current the technology is, customization, security, and post-launch support. The trouble is that the ranking scores companies on the same breadth signals as everyone else, so none of those criteria get tested against a vendor’s real answers. You can do that testing yourself, and it doesn’t take long once you know what to ask.

These five categories cover most of what an enterprise security questionnaire, a diligence request, or a parent company’s policy will eventually ask about. Use them to score any vendor, including us.

Ask whether the build will plug into the identity provider and access model your organization already runs, or whether every tool and admin panel gets its own separate login. Then ask how access gets removed when someone leaves, because that’s the question auditors care about most, and a vague answer usually means nobody has thought about it.

A badge graphic is easy to put on a page, but a questionnaire will want written answers about access control, dependency patching, backups, and what happens during an incident. Ask the vendor to show you theirs. Our own engagements start with a full audit of the code, the infrastructure, and the deploy pipeline, and the ongoing work covers exactly those four areas, because they’re the ones a reviewer will ask about by name.

Most companies searching this phrase already have a CRM, an ERP, a marketing stack, or an internal database that the new site or application has to talk to. Ask how the vendor handles data flowing in both directions, what happens when one of those systems is down, and who owns the integration once it’s live. A proposal that assumes a green field is describing a different project than the one you have.

Launch usually goes fine, so the thing to ask about is what keeps the system healthy in the years after it: whether there’s a staging environment, whether every change gets reviewed before it ships, whether automated tests catch regressions, and whether there’s a rollback plan that holds during a major framework upgrade. We deliver major Rails and Ruby upgrades with zero downtime, and if Rails is your stack, our Ruby on Rails page goes through the specific questions to ask about upgrade history, test coverage, and code review.

Ask who, by name, will answer for the architecture a year from now. A rotating bench of developers can build a perfectly good site and still leave you with nobody who can explain why a decision was made. This is as fair a question for a large agency as for a small one, and the quality of the answer tells you a lot about how the engagement will feel in its second year.

A lot of people searching for enterprise web development don’t work at an enterprise. They work at a growing company whose requirements got handed down from someone bigger: an enterprise customer’s procurement team, an investor running diligence, or a parent company rolling out its compliance policy to every subsidiary. That matters for the shopping list, because what you need is a vendor who can pass that particular test and help you answer it in writing, and that might not be the biggest name on page one.

It helps to get the original document in front of you before you talk to anyone. If a customer sent a security questionnaire, the questions in it are your real requirements, and each one maps onto something in the checklist above. The same goes for an investor’s diligence list, and in either case you want a vendor who’ll walk through those specific questions with you.

Sometimes the honest read is that the gap isn’t a single build at all. If what the customer or investor is really asking is who owns your technology, that’s a leadership question, and it covers things like answering enterprise security questionnaires, sitting in on investor diligence, and deciding whether to rebuild or patch. Our fractional CTO page describes how we take on that role.

There are web projects where size genuinely matters. If you’re launching or replatforming dozens of regional or brand sites at the same time, each with its own content team, its own legal review, and its own launch date, you need enough people to run those tracks in parallel, and a small team will turn a coordinated rollout into a long sequence. The same goes for a program where the website is one piece of a multi-year systems overhaul across several departments with its own steering committee. In those cases a large integrator’s headcount is doing real work, and you should still run them through the five questions above.

Find the document that put the word “enterprise” in front of you, whether that’s a questionnaire, a diligence list, or an RFP, and sort its questions into the five categories above, so you know which ones each vendor has to answer. Then take those five categories into your next vendor calls and compare the answers side by side instead of comparing logo walls.

If your stack is Rails, our Ruby on Rails page covers the change-management questions in more depth, and if you’re taking over an application someone else built, existing products describes how we pick those up. When you’d like to go through your questionnaire with us, you can book an intro call.