The contract for that project should name who owns the site, the content, and any custom code. This page does not set a default. Templates and third-party services stay under their own licenses.
Website development
Websites and web applications for the work itself.
A site should make the business legible. An application should let someone finish a job. Orvia House designs and builds both, including the redesign or migration when the current platform is in the way.
- Company websites
- Landing pages
- E-commerce
- Portals
- Web applications
01 — Builds
Five kinds of website work.
- 01
Company websites
The public explanation of a business: offer, proof you are allowed to show, and a way to start a conversation. Fits when The business is hard to understand from the current site, or it does not have one.
- 02
Landing pages
A single path for one offer, one audience, and one next step. Fits when You are testing a specific offer and the rest of the site would dilute it.
- 03
E-commerce
Catalog, product pages, and checkout through a payment provider you choose. Fits when You sell goods online and the operational side of an order matters as much as the storefront.
- 04
Portals
A signed-in place for customers or staff to see status, documents, or tasks. Fits when The work has outgrown email attachments and shared spreadsheets.
- 05
Web applications
Software people open to finish the same job again: records, roles, and permissions. Fits when A website can describe the job, but someone has to complete it in software.
02 — Fit
Who this is for.
Founders and operators who need the public site, the customer portal, or the internal tool built as one project. Technology companies, professional services, recruitment firms, stores, and teams replacing a stack of spreadsheets.
It is a poor fit if you want a branding package, a social media retainer, or an advertising campaign. We will say so.
A project is also a poor fit when the content, the offer, or the decision-maker is not available. We can help structure the pages. We cannot invent the business.
03 — Delivery
The whole practice, not a slice of it.
Discovery, strategy, design, development, integration, testing, deployment, and agreed support stay together. You should not have to brief a second vendor to connect the form you just paid for.
- One written scope, including what is out
- Review points while a change is still cheap
- Integrations named before they are assumed
- A handover a colleague can follow
04 — Website or application
Information, or software people return to.
An informational website helps someone understand the business and take a next step. A web application is software people use to complete recurring work.
| Question | Website | Web application |
|---|---|---|
| Purpose | Explain the offer and route a person onward. | Let a person finish the same job again. |
| What it holds | Pages, a catalog, a campaign, a clear next step. | Records, roles, and a workflow. |
| How it changes | Editorial updates and new pages. | Features, permissions, and operational rules. |
| A good sign | The right visitor understands what to do. | A user finishes the job without a side spreadsheet. |
05 — Redesign and migration
Change the structure, or move house.
A redesign changes what the site is for and how it is organized. A migration moves content, accounts, or URLs onto a platform that can carry the next version. Many projects need both. They are estimated separately because the risks are different.
We do not promise that rankings, traffic, or revenue will hold through a move. We do plan which addresses must keep working, what redirects are required, and how content is checked before the old system is switched off.
Selected work of this kind sits further down the page.
06 — Technology
The stack follows the job.
A content site can be a well-structured site with an editor. A portal needs accounts and roles. A store needs a catalog, tax handling, and a payment provider the business already trusts. A product with a real workflow needs a data model before it needs a framework fashion.
We do not publish a single required stack. The choice is written into the project, with the maintenance consequences next to it. If your team must live in the codebase, that constraint counts.
07 — Quality
Performance, access, search, and the week after.
- 01
Performance
Pages should become usable quickly on an ordinary phone. We cut weight before we add decoration. We do not promise a particular score as a contractual result unless the scope says so.
- 02
Accessibility
Semantic structure, keyboard access, labels, contrast, and a visible focus. The target for this marketing site is WCAG 2.2 AA. A product project states its own target in the scope.
- 03
Search
Clear titles, descriptions, headings, and addresses. Search performance is not guaranteed. A migration includes a redirect list so known URLs do not disappear by accident.
- 04
Maintainability
Someone should be able to change the common things without a rewrite: a page, a price, a status, a role. We document those edits in the handover.
08 — Stages
What we do, and what we need from you.
| Stage | What we do | What we need from you |
|---|---|---|
| Discovery | Map the users, the job, and the systems already in place. | Access to the people who do the work, and to the current site or tool. |
| Strategy | Write the outcome, the non-goals, and the measure of done. | A decision-maker who can confirm the scope. |
| Content | Structure pages, fields, and the words the interface needs. | Source material, or time with the person who knows the offer. |
| UX design | The paths, the interface, and the review points. | Feedback on the paths while they are still cheap to change. |
| Development | Build the site or application and the integrations in scope. | Accounts, credentials, and a staging place we are allowed to use. |
| Testing | Check the paths, the obvious errors, accessibility basics, and the integrations. | Someone from your side to try the real tasks. |
| Launch | Deploy, point the address, and watch the first real use. | The domain and DNS access, if a domain exists. |
| Handover | Notes for editing, a list of what is live, and the support terms. | The people who will own it after we step back. |
09 — Scope, cost, time
What moves the estimate.
There is no public package and no rate card on this site. An estimate is specific to the project. These are the levers, not a price.
- Number of templates, roles, and languages
- How ready the content is
- Integrations and the access those systems allow
- Migration volume and the redirects that must survive
- Compliance or procurement review
- The support window after launch
A deadline is real only when the inputs above are available. We do not guarantee a launch date in a sales conversation.
11 — Questions
Website questions.
Editorial pages should have an editor a non-developer can use. A web application is different: your team changes records inside the product, and product changes stay in the project. We write down which is which before build.
Yes, when the scope names them and those tools expose an access method we can use. We do not claim that every product on the market can be connected.
Support after launch is agreed per project: what is included, for how long, and what is a new piece of work. Nothing on this site is a standing retainer.
Send the problem, the outcome, and any deadline that is real. The contact form opens an email draft to the studio. You send that email yourself.
Start
Start with the site or the application you actually need.
A project starts when the work is clear enough to scope. The contact page opens an email draft to the studio. You send that email yourself.