Who owns the code when the project is finished?

You do. The repository lives in your GitHub or GitLab organisation, cloud accounts are opened in your name, and the application runs on infrastructure you control. We hand over architecture documentation and a recorded walkthrough so another developer can continue without asking us for a password.

How do you keep us from ending up locked into software nobody can extend?

We avoid private frameworks and build on tools any competent developer already knows, such as Next.js, Node.js, PostgreSQL, MongoDB and Laravel. The setup steps live in the repository README, so a new developer can run the project locally in an afternoon. If you hire in-house engineers later, we onboard them directly.

Can you take over an application someone else built?

Yes. We begin with an audit of the codebase, data model, authentication and deployment, and report on what is fragile. You get a written assessment and a prioritised plan before anyone proposes a rebuild.

How do you handle logins, roles and permissions?

We use established options: email and password with verification, or OAuth through Google or Microsoft, plus role-based access control. Roles are defined before screens are written, so an office administrator, a driver and a client each see only the records that concern them.

What happens after launch if usage grows?

The application runs on managed platforms such as Vercel, Railway, AWS or a Cyprus host, with monitoring and scheduled database backups from the first release. Growth usually means adding indexes, moving slow work into a job queue and upgrading the database plan rather than rewriting the product.

Custom Web Application Development

We design and build full-stack portals, dashboards and SaaS products with authentication, roles, data models, deployment and source code you own.

See our work:

Big Mail Project→KOKO-MIX ADMIN→SmartAIChats→

Most companies reach the point where a spreadsheet, a shared inbox and a few disconnected subscriptions no longer describe how the business runs. Quotes get versioned by email. Finance exports CSV files to reconcile invoices by hand. Everyone can see that software shaped around their process would remove the mess, and the same people have watched a competitor pay for a custom system nobody could change afterwards.

That fear is reasonable, and it shapes how we work: documented tools any developer can hire for, source code in a repository you own, setup instructions treated as part of delivery. A custom application should be an asset you control, not an invoice you cannot leave.

What counts as a custom web application

A web application stores data, shows different things to different people, and changes state when they act. Users log in, roles decide what they can reach, and the records they create persist for the next person. Portals, admin panels, booking engines, operations dashboards and SaaS products all share that shape.

The difference from a marketing site is where the engineering sits. A brochure site publishes fixed pages, which we cover separately under zero-maintenance static websites, where hosting is cheap and the maintenance surface is small. An application needs a database, a server layer, authentication and a release process that survives a bad deploy. A database-backed portal adds cost and risk to a site that only needed pages, while a static build cannot answer a question about today's stock levels.

Who it is for

Operations teams running scheduling, stock movements or field reporting in spreadsheets that have outgrown them
Founders building a SaaS product who need a first version customers can pay for and data that survives the second month
Companies that bought an off-the-shelf platform and found two or three required workflows missing, with no roadmap to add them
Businesses that need a client, partner or member portal attached to an existing website
Teams inheriting software from a contractor who has gone quiet and want an independent opinion before spending more

If the requirement is registration, subscription plans and restricted content without operational workflows, our membership and gated content systems work fits better.

What we deliver

Architecture and data model

We start with the entities: what a customer is, what an order is, which fields matter, and which relationships must hold. The schema comes before the screens, because a data model that ignores how the business works makes a system expensive to change later. PostgreSQL and MongoDB cover most needs, and database design and migration sits in this stage when existing data has to be moved.

Authentication, roles and permissions

Login by email with verification, or through Google or Microsoft. We define roles first and screens second, so each user type reaches the records that concern it. Sensitive actions are checked on the server as well as in the interface.

The application itself

Server-rendered front ends in Next.js, APIs in Node.js or Laravel, and background jobs for slow work such as reports, email or file processing. When the product needs a language model, document parsing or classification, we build it in the AI development track rather than attaching a widget.

Integrations

Payment providers, accounting software, CRMs, SMS and email rarely work the way their documentation suggests first time. We build the connection layer, handle retries and partial failures, and record which system owns which data under API development and integration.

Deployment, backups and tests

Applications run on managed infrastructure with automated deploys, staging separate from production, error tracking and scheduled database backups, and the deployment runbook is handed over. Critical paths get automated tests, so a later change does not quietly break billing or permissions. The repository carries setup instructions, environment variables and a map of how the services connect.

How an engagement runs

Application work moves in phases, because requirements change once users see the first screens.

Discovery takes one to two weeks: process interviews, a draft data model, and a scoped first release with a written list of what is out of scope. We prototype the riskiest part in that window, usually the integration or calculation the product depends on.

The main build runs in two-week cycles. Each cycle ends with something you can click through on a staging URL, so feedback lands on working software. Priorities get reordered between cycles.

Launch covers production deployment, data migration, user accounts and training for the people who will use it daily. Most clients continue under a support arrangement, described in website maintenance and support, or take the code in house.

A first usable release typically lands inside eight to sixteen weeks for a focused portal or internal tool. Products with billing, multi-tenant separation and complex reporting take longer, and we say so before you commit.

Handover and code ownership

Handover decides whether the software stays an asset. The Git repository is created inside your organisation's account, not ours, and cloud accounts are opened in your name with your billing details. We work inside them as invited collaborators, and when the engagement ends our access is removed and nothing stops running.

Handover material covers the architecture, the data model, environment variables, deployment steps and where third-party credentials live. We record a walkthrough so a developer who has never seen the project can follow the same path. If you hire in-house engineers, we meet them, answer questions and stay available for a defined period of paid support while they take over.

No proprietary framework holds the product in place, and no encrypted deploy process exists that only we can run. If you move the work to another team, they start from a normal codebase with normal tooling.

What it costs

Application development runs at our flat rate of $39 per hour, or as a fixed scope once discovery has produced a requirements list we can both read. Larger products are usually better served by the monthly capacity plans from $2,699, which give you a dedicated team that already knows your domain. The pricing page explains both models and the tradeoffs of each.

Scope drivers are the features that touch money, permissions and data integrity: subscription billing, multi-tenant separation between client organisations, migration out of a legacy system, mobile or offline clients, and integrations with software that has a poor API. A five-screen internal tool for one office and a multi-tenant SaaS platform with billing are both web applications, and their timelines differ by months.

Proof

SmartAIChats is a conversational SaaS product built on React, Next.js, Node.js, Express and MongoDB, with OpenAI generating the responses. It proves we can ship a product with its own commercial model and a pricing path that lets customers start small and expand.

The Big Mail Project moved an offline activity, sending postcards, into a web product users could complete from start to finish, on Laravel, Node.js, React and Next.js with MongoDB and MySQL behind it. It shows the shape we leave behind: a foundation a later team can extend without a rebuild.

KOKO-MIX Admin is an internal operations system for a ready-mix concrete producer, combining an Android app for drivers, an admin panel for the office and real-time chat over Firebase. It shows what a purpose-built internal tool does for a company whose coordination problem lived in phone calls and clipboards.

Related services

Web development for the wider range of front-end and back-end platform work we take on
AI development when the application needs language models, document processing or automation inside the product
API development and integration for the connections between your application and external services
Database design and migration for schema work, query performance and moving data out of an older system
Vibe-coded app rescue when an existing application needs an audit before it carries real users and payments

Next step

Describe the process you are trying to get out of spreadsheets, who will log in, and the systems the application has to talk to. We will say whether a custom build is justified, what the first release should contain, and what we would leave out.

Contact us with a short description of the workflow, or run your requirements through the Vasilkoff.info estimator for an initial scope and cost range.