Interface
Screens, states, tables, filters, forms and a clear user route between actions.
Logic
Calculations, search, sorting, roles, data storage, admin part and API integration.
Stock
I separate the first version from future features so that the MVP can be tested and developed without a complete rewrite.
What can be implemented as a web application?
A web application is suitable for tasks where the user must not only read content, but also enter data, perform actions and receive a result.
- Personal account. Profile, requests, statuses, files, operation history and personal settings.
- Calculator or configurator. Calculation of the cost, selection of equipment, formation of the result and transfer of the request.
- Mini-CRM. Contact list, filters, responsible, statuses and basic internal analytics.
- Catalog with logic. Search, sort, filters, favorites, compare and connect to an external data source.
- Internal tool. Automate a repetitive operation that the team currently performs manually in spreadsheets or messengers.
When is an app needed, and when is a site enough?
The site presents information and collects requests; web application processes data and supports repeated user actions.
| Scenario | Enough site | Need a web application |
|---|---|---|
| Service presentation | Pages, cases, contacts, form | Usually not |
| Calculation or selection | A simple static table | Formulas, conditions, saving the result |
| Working with clients | Application in Telegram or email | Cabinet, statuses, roles, history |
| Catalog | Small list without complex filters | Large amount of data, search, API, sync |
How to start without unnecessary risk?
The first version is worth limit to one main scenario that can be tested on real users.
- Describe action. Who is the user, what does he input, what is the result expected and who processes the data afterwards.
- Separate the mandatory. Functions without which the script does not work are included in MVP; wishes for convenience move to the next stage.
- Design States. Empty lists, errors, downloads, successful operations, and mobile behavior are scheduled before programming.
- Check and extend. After a working prototype, it becomes clear which functions are really needed and which only increased the budget.
What is important to know before starting?
Do you need a ready-made white paper?
No. It is enough to describe the problem, the users and the desired result. The list of screens and functions can be generated during decomposition.
Can I connect an external API?
Yes, if the service has documentation and access. Before the assessment, I check authorization, limits, data format and integration restrictions.
Will the app work on a phone?
The web application can be adapted to a mobile browser. A stand-alone app for the App Store or Google Play is rated as a different format.
What does the budget depend on?
From the number of roles, screens, states, integrations, access rules, data volume and administration requirements.