A Web Development Intro for Buyers, Not Bootcamp Students
Every web development intro on the first page of Google teaches someone to write JavaScript. That serves an aspiring developer well. Operations leaders signing a $180,000 statement of work, IT executives explaining why a Salesforce integration doubled the timeline, and RevOps teams that inherited a website nobody documented face a different problem. Emagin Technology wrote this web development intro for that person: the one who will never write a line of code but still has to scope the build, read the proposal, and govern what ships.
What does a web development intro look like when you are buying, not building?
A buyer’s web development intro defines the four build layers, the roles behind each invoice line, and the cost drivers vendors gloss over, rather than teaching syntax. Vocabulary equips operations or IT leaders to challenge a proposal, question a timeline, and recognize when AI-native architecture decisions get skipped before the first screen exists.
Web development means building the software that runs in a browser or mobile app: the pages a customer clicks, the logic that processes an order, and the database that remembers what happened. Everything past that definition is a decision about who builds which piece, in what order, and at what cost. Web development for business now means integration and AI-native architecture decisions as much as page design, which is exactly what most technical primers skip.
The four layers of any web build, in plain terms
| Layer | What it is | Common technologies | What it means for your budget |
|---|---|---|---|
| Front-end | Everything the user sees and clicks | JavaScript, React | Design changes and browser support drive scope creep here |
| Back-end | Business logic, authentication, processing | Node.js, Python, .NET | Integration complexity with Salesforce or an ERP lives here and drives timeline |
| Data layer | Where records live and how they get queried | PostgreSQL, MySQL | Migration and data quality problems surface late, and get expensive fast |
| Infrastructure | Where the app runs and how it scales | Amazon Web Services, Azure, Vercel | Ongoing hosting and observability costs start here, not at launch |
That table is the web development stack in practice: four layers, each with its own vendors, versions, and failure modes. Front-end development builds what a user sees and touches: layout, interaction, how a page behaves on a phone versus a laptop. Back-end development builds what a user never sees: the logic that validates a discount code, checks inventory in an ERP, or decides whether a record syncs to Salesforce. A page can look finished on the front end while the back end that makes the page functional is still weeks from done, and that gap is where most timeline disputes start.
Which roles actually appear on the invoice?
A build typically bills front-end developers, back-end developers, a full-stack developer role for smaller scopes, a DevOps engineer, QA, and a product or UX lead. Fixed-bid proposals routinely omit DevOps and QA as separate line items, folding their hours into “development,” understating true cost by 20 to 30 percent.
- Front-end developer: builds the interface in JavaScript and React; billed per screen or component complexity.
- Back-end developer: builds logic in Node.js, Python, or .NET; billed against integration count, not page count.
- Full-stack developer: covers both layers on a smaller build; adequate for a single application, insufficient once a project touches multiple systems.
- DevOps engineer: owns the deployment pipeline and infrastructure; often billed as a fraction of a developer’s time rather than a dedicated role, which surfaces later as slow releases.
- QA: tests before release; when absent from the quote, the client becomes the QA team after launch.
- Product or UX lead: decides what gets built before developers touch the code; skipping this role is the most common cause of expensive mid-project scope changes.
A single full-stack developer role suits a simple application with one data source and no ongoing integration work. A team becomes necessary once the build touches Salesforce, an ERP, or more than one identity provider, because no individual carries front-end, back-end, DevOps, and QA responsibilities at production quality once the integration count climbs past two or three systems.
Why AI-native architecture is now a day-one decision
AI-native architecture means the retrieval layer, model routing, evaluation harness, and permission model are designed before the first interface screen, not added after launch. Retrofitting AI onto a conventional CRUD application requires rebuilding the data layer to support retrieval and re-auditing every permission path, costing more than architecting for AI from the first commit.
As an Anthropic Certified Partner, Emagin Technology architects every product AI-native from the first commit rather than retrofitting models later. Model, retrieval, and permission layers appear in architecture documents before the first UI screen exists, which is the structural difference between a website with a chatbot bolted on and an AI-native web application built to reason over your data from day one. Structurally, four things get decided early:
- Retrieval layer: connects the model to your actual records, Salesforce objects, ERP tables, PostgreSQL data, instead of relying on training data.
- Model routing: sends simple queries to a fast, cheap model and complex reasoning to a stronger one, which controls cost per request.
- Eval harness: tests model output against known-good answers before a release ships, the same discipline QA applies to code.
- Permission layer: enforces who can ask the model to see what, a control that matters far more once the model can query live customer or financial data.
How does a web build connect to Salesforce, your ERP, and your data?
Most mid-market web builds are integration projects wearing a website’s clothes. A build connects to Salesforce and an ERP through REST APIs, webhooks, and middleware, with identity handled by SSO or SAML. Integration count determines timeline more than page count: three connected systems with inconsistent data models add more schedule risk than thirty pages of static content.
Every additional system a build has to talk to adds a discovery phase, a mapping exercise, and a testing cycle that has nothing to do with the interface a user sees. A REST API contract with a legacy ERP that returns inconsistent field names costs more engineering time than the entire front-end for that same page. Scoping a build on page count while ignoring integration count is the single most reliable way to end up with a proposal that is wrong.
The cost line items vendors leave out of the quote
A custom web application for a mid-market company, one with two or three system integrations and a full role set on the team, typically runs $120,000 to $350,000 for the initial build. Construction costs end there. First-year expenses after launch typically add another 15 to 30 percent of the original build cost across six categories.
| Cost line item | Why it’s missed | Typical share of year-one spend |
|---|---|---|
| Hosting (AWS, Azure, Vercel) | Quoted as a placeholder estimate, not actual usage | 5-8% |
| Observability and monitoring | Treated as optional until an outage happens | 3-5% |
| Dependency upgrades | React, Node.js, and library versions age out of security support within 12-18 months | 4-6% |
| Accessibility remediation (WCAG 2.2) | Skipped at launch, required after a complaint or a contract clause | 3-5% |
| Security patching | Assumed to be “included” without a defined cadence | 3-5% |
| Content operations | Nobody owns publishing once the agency leaves | 2-4% |
Add those six lines together and a $200,000 build carries $30,000 to $60,000 in first-year costs that never appeared in the original proposal. Understanding true web development project cost means adding those lines to the build price, not treating the initial quote as final.
How to read a web development proposal in fifteen minutes
Reading a proposal well means checking five things in order: repository ownership after signoff, deployment pipeline structure, how requirement changes get priced, what handover artifacts get delivered, and what happens contractually in month 13. Proposals that answer all five in writing are far more trustworthy than ones that only list deliverables and a price.
- Repository ownership: confirm the client’s name is on the repo from day one, not transferred or withheld at final payment.
- Deployment pipeline: ask whether releases are automated (CI/CD) or manual, since manual pipelines mean slower fixes after launch.
- Change pricing: find the clause defining what counts as a “change request” versus a bug fix, and the rate it’s billed at.
- Handover artifacts: confirm documentation, credentials, and architecture diagrams are contractually delivered, not offered as a courtesy.
- Month 13: ask directly what the vendor’s relationship to the product looks like once the warranty period ends.
Build in-house, hire an agency, or use a platform?
| Path | Best fit | Decision rule |
|---|---|---|
| In-house team | High integration complexity, frequent change, existing engineering leadership | Choose this if releases ship weekly and a technical org already exists |
| Agency or consultancy | Mid-market builds with two to five system integrations and no internal bench | Choose this if there’s a defined end date and Salesforce or ERP integration work |
| Platform (low-code/no-code) | Single-purpose tools, internal apps, low integration count | Choose this if the need is a form, dashboard, or workflow rather than a customer-facing product |
Should a company build in-house or hire an agency? The answer depends on integration complexity more than budget. A company running two or fewer systems with a stable internal team can build in-house without much risk. A company connecting Salesforce, an ERP, and a data warehouse, with a launch date and no bench of full-stack developers on staff, gets a faster and cheaper outcome from a consultancy that has already run that integration before.
What a disciplined delivery process should look like
A disciplined delivery process runs four phases: assessment of current systems and integration points, architecture decisions made before code, iterative delivery in short cycles with client review, and defined post-launch ownership. Emagin Technology’s cadence for shipping products came from running a 170-person enterprise technology organization, and applies the same sequence to client integrations.
- Assessment: inventory existing systems, integrations, and data quality before scoping a single feature.
- Architecture: decide data model, integration points, and AI-native structure before writing interface code.
- Iterative delivery: ship in review cycles measured in weeks, not a single release six months out.
- Post-launch ownership: assign a named owner for hosting, security patching, and content operations before launch day, not after the first incident.
Where to start this week
- Inventory current web properties and their integrations. List every system a website or application touches today: Salesforce, ERP, payment processors, identity providers. Most operations leaders find at least one undocumented integration during this exercise.
- Define one measurable outcome for the build. Not “modernize the website,” but a number: cut lead response time from four hours to fifteen minutes, or reduce manual order entry by 80%.
- Run an AI readiness check before scoping. Confirm whether the data layer, PostgreSQL or otherwise, is structured well enough to support a retrieval layer, before a vendor quotes a chatbot feature that can’t reach the real data behind the application.
Emagin Technology scopes client builds the same way the company scopes its own products: assessment first, architecture second, code third. Ebrahim Abdulsattar reviews proposals with operations and IT leaders before a contract gets signed, not after a timeline has already slipped. If the three exercises above surface more questions than answers, that gap is the proposal conversation worth having before a vendor sends a quote.
This article was drafted with AI assistance and reviewed by its author before publication.