← Practice · October 5, 2026
We use our own projects to show how AI shortens development time, what full-service website development includes, and which decisions remain a human responsibility.
8 min readwebsites

Building a website with AI in 2026 makes it possible to go from a brief to publication in days. At IKORG, we use AI for code, text, and graphics, while we define the structure, check the results, and launch the site. Our work includes the 701-page KUSHVATEKHPROM catalog, built in 1 day, and the 80-page Eden dental clinic website, prepared in 2 days. These are completed projects that give us concrete grounds for discussing timelines.
Development becomes faster and cheaper when we do not have to assemble every page manually and rewrite repetitive code. AI can reduce that workload severalfold. But clients care about the result, not AI itself: content, loading speed, easy edits, and a working website on their own domain. Below, we show what we built, where the savings come from, and which tasks remain with people.
AI speeds up individual operations: writing code to a brief, suggesting design options, and drafting text. When the structure is clear and the source materials are ready, we can reach a result that can be viewed and discussed sooner. Edits do not require us to repeat the entire development process either.
Our website lists 3 design options in 5 minutes, a finished website in 2–4 days, deployment to hosting and a domain, and instant edits. But design options and a launched project are different stages. The chosen direction needs accurate information, checks, and preparation for publication. The timeline for a particular project depends on its scope: our case studies also include a project that took 7 days.
Savings come from reducing manual work. Clients do not need to pay for lengthy assembly of similar pages when those pages can be generated from prepared data. Discussing the task and checking the content still matter: there is no point in speeding them up by letting errors slip through.
Those who keep building websites the old way pay for weeks of manual work that can already be automated. Those who have switched get a website in days and spend their budget on content instead of laying out similar pages. The gap between these approaches grows every month.

This is how the portfolio looks on the ikorg.ru homepage: each project lists its timeline, page count, and measured speed.
We present projects of different sizes to show that page count alone does not determine development time. A catalog built from prepared data can take less time than a small website where each section needs a separate solution.
The table lists our project timelines and approximate loading times. These are results from specific projects, not a promise of identical performance for every future task.
| Website | Niche | Timeline | Pages | Loading time |
|---|---|---|---|---|
| Website for a Member of the Legislative Assembly of Sverdlovsk Oblast | Politics | 3 days | 22 | ~1.1 s |
| KUSHVATEKHPROM | Shut-off valve catalog | 1 day | 701 | ~0.3 s |
| IgraySrazu | Song chords | 4 days | 31,842 | ~1.5 s |
| Kratchaysheye.rf | Summaries of school literature | 7 days | 2,419 | ~2.9 s |
| MONIK | Trucks with loader cranes and tow trucks | 1 day | 46 | ~1.0 s |
| SLADIS | Sugar-free foods | 3 days | 160 | ~1.2 s |
| Eden Dental Clinic | Dentistry in Yekaterinburg | 2 days | 80 | ~1.0 s |
| RADO | Freight transport and vehicle servicing | 3 days | 25 | ~1.5 s |
| Bolshaya Medveditsa Settlement | Settlement | 4 days | 28 | ~1.0 s |
All the listed projects except the legislator's website have a PageSpeed score of around 100. The links in the table are live: you can open each project and check its speed yourself.
The table entries also involved additional tasks. The SLADIS catalog contains 63 products. Bolshaya Medveditsa has an English version. We migrated MONIK from WordPress to a static website and preserved the old image URLs to avoid losing search rankings.
These examples show the main point: a short timeline is compatible with a large catalog, multiple languages, and migrating an existing project. But the scope of work needs to be defined before the build starts.
An “AI-built website” can mean different things. In one case, a person gets a page inside a website builder; in another, they get a finished project deployed to hosting and accessible through a domain. For the client, the main difference is who sees the work through to completion.
An AI website builder can help produce a starting point: a block layout, styling, and draft text. Then someone needs to work out whether the structure fits the task, the wording is accurate, the sections are complete, and what is needed for publication. The specific capabilities depend on the service chosen.
In our full-service work, we handle the entire process, from defining the task to deploying the website. AI is part of that process, while the client discusses the result with us. They do not need to turn generated code into published pages themselves.
For a catalog, for example, we need to determine in advance what data a product card should contain and how visitors will find the item they need. For a service website, we need to create a clear path from the description of the service to making an inquiry. An attractive first screen does not solve these tasks automatically.
If you want to commission a website built with AI, it helps to clarify what the deliverable includes: who prepares the content, checks the pages, migrates the materials, and publishes the project. The term “AI” does not replace an agreement about exactly what should be ready when the work is complete.
We build static websites with Astro and host them on Beget. During the build, Astro prepares the HTML pages that visitors then receive. Serving this content does not require PHP or database queries every time a page opens.
This helps keep the technical setup simple and loading times short. But it would be wrong to attribute the entire result to AI: it writes the code, while we choose the architecture. AI can easily produce a slow website if we do not pay attention to what it has built.
Without PHP and a database, the website does not have the most common vulnerabilities: there is no CMS or plugin software to update and no admin login form to brute-force. Hosting and domain credentials still need to be protected, of course.
We build large websites from tables and data. First, we define the page structure, then use prepared records to populate it. This lets us work with tens of thousands of pages without laying out each one manually.
Checking the source materials is especially important here. An error in a shared template or a table field can appear across many sections. Automation therefore makes careful preparation more valuable: the larger the volume, the more important a correct data structure and clear rules for using it become.

IgraySrazu: 31,842 song pages built from a data table in 4 days.
We use Claude Opus, GPT, and Gemini in our work, and GPT Image and Nano Banana for image generation. AI writes code, prepares text, and creates graphics. Choosing a tool helps us complete a specific task, but it does not remove our responsibility to check the result.
Defining the task remains a human responsibility. AI does not inherently know which services take priority, what matters to visitors, or which information the client can confirm. We need to establish these things and turn them into website requirements.
Facts need checking. Confidently written text is not necessarily accurate. We must check product specifications, terms of service, company information, and service descriptions against the source materials. If information is missing, we need to request it instead of filling the gap with a plausible answer.
Legal texts need separate attention. AI can prepare a draft, but it should not independently define a company's obligations or approve document wording. These materials need to be checked against the client's actual business activities.
Decisions and responsibility remain with us. We choose which suggestions to use, what to fix, and what not to publish. Clients need an identifiable provider with whom they can agree on the result. Pointing to a model error instead of fixing it is no way to deliver a complete website.
We structure the process so that at every stage, it is clear what has been decided and what still needs agreement.
AI is especially useful between discussing an idea and showing the result: we can quickly turn an idea into a page and assess it in concrete terms. This reduces the time spent explaining, but it does not remove the need to agree on the content. The more precise the source materials and feedback, the less we need to rework sections that have already been built.
That risk exists if we accept AI's first suggestion without working on the structure and design. We use generated output as material to choose from, then adapt the pages to the project's task. Differences should come from the content, the choice of sections, and usability, rather than random decorative details.
Yes, when the data is prepared and the page template is clear. Our KUSHVATEKHPROM project has 701 pages built in 1 day, and IgraySrazu has 31,842 pages built in 4 days. These timelines cannot automatically be applied to any catalog: we first need to assess the state of the materials and the build requirements.
It can prepare drafts, but the client needs to provide the source information about the company's work. We must not invent specifications, terms, or benefits. Client involvement is especially important where the text makes concrete promises: exactly what a customer will receive and on what terms.
Speed is important, but it is not the only factor: search engines also consider content and mobile usability. A fast website provides a good foundation, but rankings also depend on the text and competitors in the niche, so we cannot honestly guarantee a position in search results. When migrating an existing website, we preserve old URLs, as we did with MONIK, to avoid losing what has already been gained.
We need to start with the features visitors require. Our work includes service websites, catalogs, and large informational projects built with a static architecture. If the task involves user accounts, constantly changing personal data, or complex operations, the technical solution needs a separate discussion. Choosing a technology solely for its generation speed is the wrong approach.
Our experience shows that a website can be launched in days and repetitive work can be significantly reduced. Savings come from automating code, content, and builds. That is what we use AI for, while retaining responsibility for defining the task, checking the work, and the published result.
You can see all our work in the portfolio on the homepage. And if you want an idea of what your website could look like, describe the task, and we will show you three design options in five minutes.