Web service development
We create customer accounts, internal systems and independent online products. We plan how to change rules and develop scenarios after the first release, based on what you learn from users.
We build customer accounts and online services where people can place orders, book appointments and obtain documents on their own.
Define the task
We decide what users should be able to do on their own. We examine how the company will handle their request and define the scope of the first version.
- From you
- An idea or prototype, a description of the task and company systems
- Step result
- Scope of the first version, user roles and a list of integrations
Test the prototype
We show future users how the service will work. We check whether the actions are clear and refine the solution before development.
- From you
- Participation from users and staff, sample data
- Step result
- Prototype and a list of development tasks
Build the service
We build the interface and connect operating systems. We check data access, error handling and recovery after failures.
- From you
- Materials, access to systems and a person responsible for approval
- Step result
- Working service with tested scenarios
Hand over to your team
We explain how the service works and work through a possible future change. We show how to release updates and restore the service.
- From you
- The team that will maintain the service
- Step result
- Code, access credentials, instructions and explanations of decisions
What can a person do for themselves?
In a customer account, someone can track a request, choose terms or pay for an order. Together, we decide which action the service should let them complete independently and what the company must provide for it.
The first release includes the entire journey from starting an action to receiving a result, including the team’s handling of the order.
The first release
A working prototype lets people try the idea before development and reveals missing details. During testing, we decide which findings belong in the first release, which replace earlier decisions and which need separate testing. By launch, there is a complete scenario that customers and staff can use.
What happens when someone changes their mind?
They return to an earlier step, close the tab or press a button again. The service must remain understandable in these situations too.
We check whether entered data is preserved, whether an error can be corrected and what a support employee will see. We work through specific cases. For example, someone pays for an order but the confirmation fails to load. The money has already been charged, but they do not know that yet.
The order is paid. What happens next?
One order, one payment
Pressing the button again does not create another payment. The service checks the status of the first payment and shows confirmation of the same order.
The order remains in the account
Closing the tab does not cancel a payment already received. When the customer returns, they see the paid order and can continue where they left off.
Staff can see what happened
The employee has the order number and payment status. The customer does not have to describe the purchase again or prove payment with a screenshot.
Preparing for later versions
The interface, operating rules and data storage change for different reasons, so we separate them in the service architecture.
We discuss likely changes, including new integrations, ways of providing service and growth in traffic. We decide what to prepare for now and what flexibility is not yet worth its cost. We consider the cost of the first release alongside regular operations, peak traffic and maintenance.
Different parts of a service change for different reasons
- CRM and accounting
- Payments
- Notifications
Why the decisions were made
We involve the future product owners in discussion before handover. Together we work through one future change: what it affects, where to find the necessary information and what to check before release. A concrete task reveals which decisions the team understands and what still needs explaining.
The team carries on
We hand over code, access credentials, integration descriptions and instructions for releases and recovery.
We also record what belongs to the company, what it uses under licence and which external services need maintenance. With these materials, your specialists or chosen developers can continue the work. You can discuss the next version knowing how the product works and why it was built this way.
What the work may include
- Choose a time
- Pay and confirm
- Booking in the schedule
Booking service
Bookings, payments and schedule management.
Partner portal
Dealer orders, individual terms and documents.
Online configurator
Choosing a configuration and calculating its price.
Learning platform
Courses, assignments and learning progress.
How the work is organised
Define the task
We decide what users should be able to do on their own. We examine how the company will handle their request and define the scope of the first version.
- From you
- An idea or prototype, a description of the task and company systems
- Stage outcome
- Scope of the first version, user roles and a list of integrations
Test the prototype
We show future users how the service will work. We check whether the actions are clear and refine the solution before development.
- From you
- Participation from users and staff, sample data
- Stage outcome
- Prototype and a list of development tasks
Build the service
We build the interface and connect operating systems. We check data access, error handling and recovery after failures.
- From you
- Materials, access to systems and a person responsible for approval
- Stage outcome
- Working service with tested scenarios
Hand over to your team
We explain how the service works and work through a possible future change. We show how to release updates and restore the service.
- From you
- The team that will maintain the service
- Stage outcome
- Code, access credentials, instructions and explanations of decisions
What we check
Data access
We check the actions permitted for each role.
Markets and accessibility
We document country requirements and test the main scenarios.
Recovery
We check backups and returning the service to operation.
What we hand over
- Source files and project repository
- Access credentials and a list of external integrations
- Instructions for updates and recovery
- Documents covering rights and licences used
- Description of user actions, data exchange and access rights.
What task should the service solve?
Tell us what people should be able to do and show us an idea, prototype or current product. We will discuss the first release’s boundaries, the receiving team’s work and an estimate of costs.
After agreeing the work
- Description of the main scenario
- Content and operating rules for the service
- Responsible person and access to the necessary systems
Review your answers
This brief is too large for a Telegram link. Continue with the bot and add the remaining answers there.
Copy the full text or attach the downloaded file to your email.
Saving is unavailable in this browser. Your answers remain available while the page is open.