Skip to main content
CyberLab.Team

Development

Web app development for tasks people do in the browser

We build browser tools that let people finish a task without installing an app. A customer portal might let someone submit a request and follow its progress. An internal tool might help staff review records or approve work. We define what each person needs to do, then build the screens and access rules around that task.

Price on request · reply within one working day

A complete browser workflow: from opening a request to seeing its outcome.

Clear account boundaries: each role gets the records and actions it needs.

A tool you can operate: source code, account access and instructions at handover.

What you get

At handover you have:

  • A user flow showing the task from start to finish.
  • Browser layouts for the devices your users need.
  • Sign-in and account settings where private access is needed.
  • Role permissions for viewing, changing and exporting records.
  • The forms, dashboards and system connections in the estimate.
  • Workflow test results and an operating guide.

Public information and private account screens have different needs. We plan search access for public pages and permission checks for private records. Keeping a page out of search does not protect the data behind it; the application checks access when someone requests a record.

What the cost depends on

We estimate from the user flow and the records it changes.

  • The steps users need to complete and the exceptions they encounter.
  • Account types and differences between their permissions.
  • Screens and devices that need different layouts.
  • Shared data and rules for simultaneous edits.
  • Connections to existing business systems or payment services.
  • File handling, notifications and reporting.
  • Testing and the operating handover.

Hosting and outside service fees are not included in the development work. A ready portal may reduce the development needed. If a requested connection cannot provide the required data, we explain the options before including it in the plan.

We answer every inquiry within one working day. The schedule depends on decisions about user roles and access to connected systems.

The custom code and application accounts stay yours. We list licenses and who maintains the application at handover. We choose who builds each part of the application, our specialists or contractors we know, and CyberLab answers for the result.

What is included and what is not

Included

  • Mapping the browser workflow and checking whether a ready tool fits.
  • Designing and building the screens in the estimate.
  • Account access and role permissions for those workflows.
  • Connections whose requirements have been checked.
  • Testing the main tasks and restricted actions, then handing over the application.

Not included

  • Deciding your service rules and who may see each record.
  • A separate mobile application and app store submission.
  • Replacing systems outside the browser workflow.
  • Hosting and ongoing technical support.
  • Public marketing content and campaign management.

You name someone who can answer questions about the records and approve how the tool changes them.

When you need this

  • Customers email for updates that could be available in their account.
  • Staff pass spreadsheets around to review or approve the same records.
  • A dashboard needs actions as well as charts.
  • A public form is no longer enough for a task with several steps.
  • A ready portal cannot support a specific part of your workflow.

How the work goes

What you have after each step

  1. Step 1. Follow the user's task

    You get a flow and a list of required records. You explain who uses the tool and show what happens when a request is incomplete or rejected.

  2. Step 2. Map the screens and access

    You get layouts and a permission map. You approve what each role can do and identify where records come from. We check ready tools before recommending a custom build.

  3. Step 3. Build and try the workflow

    You get a test application with realistic sample data. Users try the task on the target devices. We check denied actions and attempts to open another account's records.

  4. Step 4. Release and hand over

    You get test results, source code and operating instructions. You confirm the account settings and approve the release. The handover names who handles updates and user access afterward.

How we can work together

Pick the form that fits the task. We suggest one after the first conversation.

  • Consultation or audit

    For when you want a second opinion on a plan, a system or a quote before you commit. You get a written review with recommendations and an estimate of the next step.

  • Fixed-scope project

    This works when the requirements can be written down before work starts. You get the agreed scope for the agreed price. Anything new goes through an updated estimate first.

  • Time and materials

    For when the scope will change as you learn, as with research or a new product. You pay for the time spent, and we review the plan with you as the work goes.

  • Support after launch

    Your system is already live and needs updates, fixes and monitoring. We agree a monthly arrangement and a list of what it covers.

Need developers who work on your product every month? See the dedicated development team.

Platforms and tools we work with

React, Vue, Angular and Next.js in the browser. Node.js, PHP (Laravel, Yii), .NET (C#) and Go on the server. MySQL, PostgreSQL, MongoDB and Redis for data.

We choose the platform from the task, and the list shows what we use most often.

Who this is for, and when it is too early

You need a repeatable task that already exists and someone who can describe when it counts as done. It is too early if nobody can say who uses the tool.

If visitors only read information and send an inquiry, a website may be enough. If a ready portal already does the job, configuration may be smaller.

A website, a browser app or a mobile app?

OptionWhen it fitsWhat to settle first
Website with a formVisitors read an offer and submit an inquiryWhere the submission goes and whether follow-up needs an account
Web applicationPeople use records or complete an interactive task in the browserRoles, device layouts and the systems supplying the data
Mobile applicationA recurring phone task needs installation or device features beyond the browser planInstallation effort, offline needs and platform maintenance

Offline behavior needs a separate plan for local data and later updates.

Working with clients in other countries

  • Contract and NDA. You sign a contract with CyberLab.Team OÜ, a company registered in Estonia, before work starts. If you need an NDA, we sign it before you share confidential data.
  • Invoices in euros. We invoice in euros from an EU company with a VAT number.
  • Languages. We work in English, Ukrainian, Russian and Polish.
  • Calls and replies. We hold calls at hours agreed with you and reply to messages within one working day.

Frequently asked questions

Portal design

Does a customer portal need more than a sign-in screen?
Yes. Plan what the customer sees after signing in and which action they can complete. A portal needs useful records, clear status messages and a route for exceptions.
Can a dashboard include approvals as well as reports?
Yes, if that is part of the workflow. We define what an approval changes and who can reverse it, then test the action alongside the displayed figures.
Can staff and customers use different screens for the same request?
Yes. They can have different views of the same record. We define which internal notes remain private and which updates the customer should see.

Roles and private records

What if someone guesses another customer's record address?
The application must check permission for the requested record. We test direct requests as well as navigation, so hiding a link is not treated as an access control.
Can a user hold different roles in different workspaces?
That can be part of the account model. Each action must use the role for the current workspace, and changing workspaces must not carry permissions across by accident.
How should a shared device handle the end of a session?
We define sign-out behavior and which screens should require a fresh sign-in. We test what the next person on the device can reach.

Records and browser behavior

What happens if two staff members edit the same record?
We choose a rule for conflicting edits. The application can warn that a record changed and ask the user to review it rather than silently replace someone else's work.
Can users save a long form and return later?
Draft saving can be included. We define where drafts are stored, who can reopen them and what happens when required information changes before submission.
What should the app show when a report has no data?
An empty report should say whether no records match, data has not arrived or loading failed. Those states need different messages and, where useful, a next action.

Device use and release

Will a browser app require an app store download?
No. Users open its address in a supported browser. Installing a separate mobile application is a different delivery route and is outside this service unless separately planned.
Can we limit the first release to desktop users?
Yes, when the users and task support that decision. We document the intended devices before design so a desktop workflow is not presented as ready for phone use.
Can the browser tool work alongside our existing website?
Often. We check domain settings and the sign-in arrangements first. The public site and private application can remain separate while giving users a clear route between them.

Related services

Send us the task people should finish in their browser

Say who needs access to the records and what they do with them. The first conversation is free, and an estimate of cost and scope follows. We reply within one working day.

Discuss your project

Telegram @cyberlabteam · WhatsApp +48 668 155 303 · info@cyberlab.team