The company website was built four years ago on a template, and for showing who they are, it works. Now sales wants customers to check their order status without sending a WhatsApp message, the portal to pull data from the ERP, and each distributor to see its own prices. The agency suggests another plugin. That would make 34.
Companies in Chile usually start pricing custom web development once the site is already failing, and by then the conversation is about putting out fires instead of what the business needs. That conversation goes better when it happens sooner, and it starts with telling apart a corporate site, a template-based CMS and a custom web platform, recognizing when you've moved from one to the next, and knowing what to check before you hire a software development company.
Three things people call "a website"
The confusion starts with the name. "The company website" can mean very different products, built, priced and maintained in different ways.
| Template-based corporate site | Customized CMS | Custom web application | |
|---|---|---|---|
| What it's for | Presenting the company, capturing leads | Publishing content often, simple catalogs | Running a business process |
| Who uses it | Anonymous visitors | Visitors and editors | Customers, suppliers or teams with their own accounts |
| Data | Text and images | Content and a few forms | Business data coming from other systems |
| Logic | Almost none | Whatever the plugins bring | Its own rules: pricing, approvals, permissions |
| When something changes | You edit a page | You look for another plugin | You change the code |
None of these is better than the others. A CMS is the sensible choice for most corporate sites, and there's a reason WordPress runs 39.5% of all websites, according to W3Techs (October 2026). Trouble starts when you ask the first or second column to do the third column's job.
Signs the template isn't enough anymore
The shift rarely starts with design. The business pushes it, and in the projects that reach us, one of these situations almost always shows up:
- The site needs data from another system: stock, order status, account balance or customer-specific prices that live in the ERP or CRM today. As long as that data is copied by hand or through a nightly export, the website will show stale information.
- There are users with accounts and different permissions. A distributor shouldn't see what an end customer sees, and a supervisor needs to approve what a salesperson enters. That's access control, and a membership plugin wasn't built for it.
- The logic has exceptions: volume discounts that vary by region, approval flows with amount limits, shipping calculations with their own rules. Every exception patched with a plugin adds a dependency nobody on your team controls.
- The process lives in Excel and email. If your team rebuilds the same information in a spreadsheet every week to answer customers, what you need is a portal, not a website.
- You handle personal data, such as national ID numbers (RUT), addresses or purchase history. Chile's data protection Law 21.719 still takes effect on December 1, 2026, while the bill that would postpone it is still being debated in the Senate. Knowing who accesses what, and keeping a record of it, stops being optional.
If two or more of these apply, you're most likely running a web application that's still being managed like a website.
Integrations: where the project is decided
A custom web platform rarely stands alone. Its value is in connecting what already exists: the ERP, the CRM, the invoicing system, sometimes an AS/400 that's been running for twenty years.
Before talking about screens, answer three questions. Does the source system expose an API, or does someone have to build the bridge? Does the integration need to be real time, or is a periodic sync enough? What happens on the website when the ERP is down?
Those answers move the budget far more than any design decision. In how much custom application development costs we explain why integrations are the most underestimated factor in a quote.
SEO and performance as technical requirements
There's a fear that moving to custom development means losing search rankings. It happens, but only when performance and indexing are left for the end. Treat them as requirements from day one and it doesn't have to.
Google says Core Web Vitals are used by its ranking systems, while noting that a good score doesn't guarantee top positions. The thresholds published on web.dev are specific enough to put in a contract:
| Metric | What it measures | "Good" threshold |
|---|---|---|
| LCP (Largest Contentful Paint) | How long the main content takes to appear | 2.5 seconds or less |
| INP (Interaction to Next Paint) | How long the page takes to respond to an interaction | 200 milliseconds or less |
| CLS (Cumulative Layout Shift) | How much content moves around while loading | 0.1 or less |
Google assesses them at the 75th percentile of real visits, split by mobile and desktop. Ask the proposal to state how they'll be measured before and after launch, and how the architecture handles them: what gets rendered on the server, how URLs and redirects from the old site are managed, and who generates the sitemap.
An application behind a login doesn't need SEO. The public pages around it do. Keeping the two apart is usually the soundest architecture call you can make.
The code has to be yours
With a template, switching providers is low risk: the CMS is standard and another agency can pick it up. With custom development, that risk depends on what you sign.
Before hiring, make sure the contract spells out:
- Whose name the repository is under and who has admin access.
- What documentation is delivered: architecture, deployment, environment variables, integrations.
- How deployment works. If going to production depends on someone at the vendor doing it by hand, you don't have real control.
- Which third-party components the system uses and under what licenses.
- What the exit looks like if you decide to change providers.
If you're comparing a software factory with a dedicated team, software factory vs. custom software development in Chile covers what changes with each model.
Frequently asked questions
Should we rebuild the whole site or just add a portal?
Splitting them usually makes more sense. The public site can stay on a CMS, which is convenient for marketing, while the customer portal is built custom and integrated with the ERP. Each part gets the tool that fits it.
Is custom web development slower than a CMS?
Not necessarily. Built well, it can be faster, because it only loads what it needs. To avoid relying on promises, write the Core Web Vitals thresholds into the acceptance criteria.
How long does it take to build a custom web platform?
It depends on scope and, above all, on integrations. A first version limited to one process lets you launch sooner and learn from real users before adding more.
Let's talk about your platform
At Disrupsoft we build custom web applications with Angular, Node.js, Azure and Power Platform, integrated with the systems you already use, such as Dynamics 365, AS/400 or JD Edwards. If your website has started carrying processes it wasn't meant for, let's review your custom development project together.
