There is one question worth asking before commissioning any web development in 2026: does this actually need to be built, or could I do it myself in an afternoon?

That question got sharper yesterday. At DevDay on 29 September 2026, OpenAI updated ChatGPT Sites, the feature that lets you describe what you want and get a working website or lightweight web app. Not a picture of how it might look. A real site, with a URL, that you can edit by conversation, publish, connect to your own domain and, in the new version, keep updated automatically.

This is not a threat to people who build software. It is a new tool that, used in the right place, saves money for the people using it and time for the people building. What matters is knowing exactly where the line falls.

What ChatGPT Sites already does

According to OpenAI's documentation, Sites creates, previews, publishes and shares interactive websites and lightweight apps. Dashboards, calendars, tracking tools, internal portals, reports and prototypes are all in scope. The process is conversational: you describe what you want, the system builds a first version, and you request changes in plain language.

It is available on the Plus, Pro, Business and Enterprise plans, the last of those requiring administrator enablement. It is not available on Free or Go. Custom domains are supported where the option exists on the account, with one important condition: you must already own the domain and be able to change its DNS records.

Yesterday's updates are twofold and both matter. First, you can now add supported plugins to the Sites you build, and each person on a team can use the same app with their own connected data and permissions. Second, Automations became easier to add and manage, so a Site can keep shared information up to date on its own, including through events coming from connected apps.

Translated: a Site is no longer necessarily a static page someone updates by hand. It can be an object that updates itself. That puts it much closer to an internal application than to a page builder.

Where this is genuinely a good idea

Let us be direct, because this is the part that matters to the reader and it costs nothing to say.

If you need a prototype to test an idea before spending real money, use a tool like this. If you need a landing page for an event, a campaign or a presentation that lives for three weeks, use a tool like this. If you want a small internal dashboard for the team to track projects, or to turn a spreadsheet into something people can consult without asking anyone for a file, use a tool like this.

No company should pay thousands of euros to validate a hypothesis it can validate in an afternoon. In practice, this lowers the cost of experimenting, and lowering the cost of experimenting is one of the best things that can happen to a small business. Companies that try more things get more things right.

It is also worth naming what this puts pressure on. Firms that charge project rates for installing a template, swapping the logo, changing four colours and adding a contact form will have fewer and fewer arguments. That pressure is healthy, and it forces anyone who builds to show what they are actually charging for: strategy, conversion, integrations, architecture, measurement, rather than production hours.

Where the conversation changes

What these tools solve is interface production. As it happens, in a business website the interface is the smallest part of the job.

Think about a working online shop. The customer sees product pages and a cart. Behind it sit the catalogue, stock, invoicing, payments, carriers, order management, Google feeds, cookie consent, transactional emails, CRM, analytics and, almost always, a management system the company was already using before it had a shop. We call it a website. It is a system.

The same is true of a booking portal, a customer area, a training platform or a site that generates quotes from rules of its own. The question stops being "can it build this page?" and becomes "can this thing live inside the company's operation?".

And there is a layer no tool decides on its own: who the customer is, what information they need before buying, what action we want them to take, how we measure that action, where the leads go, how it connects to invoicing. AI helps implement answers at a speed that did not exist before. It does not choose the right answers for your business, because it does not know your business.

Two technically identical sites, both fast, both fine on mobile, can produce thirty enquiries a month and three. The difference lives in the order of the pages, the social proof, the photographs, the number of form fields, the way the service is explained. Those decisions do not arrive with the prompt "build me a modern, professional website".

The limits OpenAI documents itself

This part is useful because it is not our opinion, it is written in the documentation.

Some frameworks, private networks, databases, background services and hosting patterns may not be supported. Sites does not support data residency or inference residency at launch, which matters to anyone with data location requirements. Sites must not process protected health information or payment card data, except through third-party processors. And where there is commerce, OpenAI is explicit: responsibility for transactions, orders, taxes, refunds and customer support stays with the site owner.

None of this makes the tool bad. It makes it a tool, with a scope. The practical conclusion is mundane and important: there is no single tool suited to every problem.

Who owns the site

There is one point that will gain weight over the coming years and that almost nobody asks at the right moment.

When you build on a closed platform, you inherit that platform's rules. Today a feature exists, tomorrow it changes. Today the price is one thing, tomorrow another. Today an integration works, tomorrow it drops off the supported list. For a prototype, that is irrelevant. For the system that carries the operation, it is a strategic decision.

That is why, in the projects we deliver, the domain, the code and the content belong to the client. Not because we expect them to leave, but for exactly the opposite reason: we would rather they stay because the service is worth it, not because they technically cannot get out.

Being found is a separate problem

There is a dangerous idea going around: if AI built the site, it must already be optimised for AI.

It does not work like that. Building a page and building a presence that gets found are two different jobs. The second involves information architecture, content that answers real searches, structured data, internal linking, indexing, performance, authority and, increasingly, how AI systems understand who the company is and what it does. We have written about that last point in how to show up when someone asks an AI who does this in Braga.

A site nobody finds is still a site. It just is not an acquisition channel.

Six questions that settle the decision

Before choosing a path, run the project through these questions. Does it process payments or sensitive data? Does it need user accounts with different permissions? Does it have to talk to software the company already uses, such as invoicing, CRM or ERP? Does it depend on SEO to bring in customers? Does it carry business logic of its own, the kind nobody outside would guess? And what happens to the business if it is unavailable for a day?

If you answered no to almost all of it, you can probably do it yourself, and you should. If you answered yes to two or three, you are talking about software rather than a site, and it is worth treating it as software. It is the same logic we apply to AI automation, described in chatbot, copilot or agent: the right technology depends on the cost of getting it wrong.

The future for people who build software probably involves writing less code and deciding better. If a tool produces in ten minutes what used to take three hours, there is no merit in charging for the three hours. The value shifts towards understanding the problem, designing the architecture, integrating systems, measuring results and, fairly often, telling the client that a particular piece of development is not needed.

How Digito helps

The useful work starts before any code exists. We listen to what the business needs to do, say frankly what a tool like this already solves, and design and build the rest.

In practice there are three paths. Professional websites built to bring in customers, with content, structure and measurement rather than just pages. Web and mobile applications when what the company needs has accounts, permissions, rules of its own and data that cannot live on a closed platform. And software and integrations to connect all of it to what already exists in the company, from invoicing to CRM, so information does not stay trapped in a page.

If you are facing this decision now and want an honest opinion on what is worth building and what is not, talk to us at digitosolutions.com.

Sources