How to develop an online psychotherapy service in the UK and not go crazy

More than design

The customers contacted us in the autumn of 2020. One of the partners has a PhD in clinical psychology and she’s been a licensed counselor for 10 years. She specializes in trauma therapy, anxiety, and depression. Apart from counseling, she reads lectures. The other partner who specializes in management consulting was our client.

They wanted to combine their experiences and create a therapy service with custom features like calendars, notes, chat, and video calls. They asked us to design their future app. We did it but our client stayed with us to develop a mobile app and a web service.

We built a team of developers and designers, a QA specialist, and a project manager. Little did we know that we would have two managers — the client was so involved in the process that sometimes we thought he was a Purrweb employee. But we’ll get back to it later.

Unnatural selection

To start working on the service, a month-long online course in psychology is not enough. The platform is very selective — here’s what you need to get an account:

• • MA or PhD in psychology,
  • at least 3 years of practice,
  • at least £1,000,000 of indemnity,
  • a DBS certificate,
  • an ID.

When a therapist creates an account, they fill out the form, give the data from this list, and undergo an interview. After registration, they have to meet these requirements: 

• • set time slots for at least 5 sessions a week;
  • keep their calendar updated;
  • answer patients when they want to cancel or set up a meeting within 6 hours.

If therapists reject more than 5 requests in a row, service moderators contact them. Moderators have the right to block the account.

It’s much easier for patients to: create an account, customize your profile, decide on the goals — and you’re done. You can also take a survey, and the platform will set you up with a therapist. If it’s not enough, the platform has a chatbot. It will ask you more specific questions from preferable gender to payment options and it will set you up with a suitable specialist as well.

Don’t know where to start with healthcare app development?

After 300+ completed projects, we can create an app in any niche — from fintech to IoT. Contact us and get a free project estimation in 48 hours.

Find out

Surprise me!

There are too many similar apps on the UK market, so our app is not a unique product. But it’s different from its competitors in three ways:

• • Custom features: calendar, notes, chat, and video calls. We could have used ready-made solutions for almost all these functions but the client wanted to make them from scratch.

• • Adaptive screen: it’s more than adaptive design — we calculated not only the screen’s width but also its height. It’s not an easy task. But for example, a desktop app will display the whole function block without distorting the proportions or having to scroll down — even if you open it on an 11-inch laptop screen.
  • Window management: you can minimize a video call window and use other app features simultaneously — like making notes during your session.

Tech stack-wise we used all the reliable frameworks and instruments:

• • Next.js for web frontend — we needed this for search engine indexing,
  • Nest.js + GraphQL for backend,
  • PostgreSQL for data storage,
  • React Native for the mobile app.

Role-playing

We divided the development process into 14 sprints:

1. Frontend and backend architecture.
2. Authorization. We used Auth0 and SendGrid to send a confirmation letter after registration. We usually go with Auth0 for authorization through social networks — in our project, we added this feature for patients. This solution is also good for quick authorization building. And, we went with SendGrid because of its convenient letter templates and API.
3. Onboarding.
4. User flow for finding a therapist.
5. Creating a schedule for therapists.
6. Patient’s dashboard.
7. Chat.
8. Video calls.
9. Payments. During this sprint we started working on a mobile app, so we also did mobile architecture, onboarding, and registration.
10. Feedback on therapy sessions and income management. Mobile app: finding a therapist.
11. Admin dashboard and email notifications. Mobile app: finding a therapist.
12. Insurance integration. Mobile app: income management and patient’s dashboard.
13. Preparation for the release and debugging. Mobile app: chat and video calls.
14. Setting user behavior analytics. Mobile app: preparation for the release, debugging, and the release.

Service is very detailed for every user role. For example, patients can monitor all the previous and upcoming sessions, make notes, keep all the materials for therapy in one place, and track therapy goals. They can also chat with therapists and look through doctors’ profiles.

Therapists can see their schedule, calendar, income, and patients. Admins look through registration requests, existing profiles, and patients’ data, which is the requirement of HIPAA and GDPR.

Many opportunities mean many screens. And here’s where things went wrong.

Screens for everyone

Three roles require approximately 100 screens. It was even before we agreed to develop two apps — web and mobile.

During development, we were stuck upon emitted edge cases, for example, the doctor’s availability in the distant future. Rarely, do patients want to schedule a session not for the next week but in several months. But we didn’t have any screens for this scenario. We discovered it when our team was already building the app.

Since we worked on the final release instead of an MVP, this was an urgent problem. Our client wanted to go to the highly competitive market with the final product, so we refined this case.

Insurance issues

Western medicine works closely with insurance companies. Many clients have insurance that covers psychotherapy. To allow clients to use their insurance cards, we had to integrate the app we were developing with an insurance aggregator. The client suggested HealthCode which is the largest and the most popular British health-tech service.

When we received HealthCode’s API description, we were discouraged. This document was a useless incoherent mess with outdated descriptions. Our team lead had to hold an extended discussion with HealthCode tech support to get the necessary data.

Even worse, HealthCode’s API uses an obsolete data exchange format — SOAP. Our app uses JSON, like the rest of the world. That’s why we had to write a module to convert queries to our format which was time-consuming.

We could test HealthCode’s API only when a real client tried to pay with their insurance since it doesn’t have a sandbox. We braced ourselves for the first payment — and when it was successful, we were in high spirits. But the UK has a lot of insurance companies, so later we had payment failure cases. We worked on all of them with HealthCode’s tech support to fix all the integration bugs.

Another manager

We like the clients who are eager to get involved in the project and take part in it. Our client was one of them. He closely monitored the development and actively took part in our group chat. But sometimes, his micromanagement was too much — as if we had another PM in our team.

It led to conflicts. At first, we discussed solutions, implemented them, and got back to the client’s review. However, during the presentation, he asked for a different implementation even though we reached an agreement earlier. All this rework is time and money — and it’s not always obvious for non-developers. It’s only he who thinks that it’s “easy” and “requires just one more line of code.”

The truth is that service issues and new features are seldom fixed or added with just one line of code. It’s hard to explain but it’s crucial. If you don’t find common ground with your client, you’ll end up with mutual dissatisfaction. And all the pent-up grudges will lead you to a failed project.

That’s why we never stay silent in such situations. I invited the client to a “confessional”. We spent 1.5 hours negotiating because we wanted to make the communication pleasant, crystal clear, and comfortable both for him and our team.

This resulted in the following action plan. We promised to:

• • write down all the agreements after every Zoom call,
  • invite him to daily standups,
  • schedule a quick 10-minute call with our QA specialist and our developer, in case of unexpected issues.

And he promised to:

• • give up micromanagement and track our progress during daily standups,
  • perform a priority check instead of adding urgent tasks to the ongoing sprint,
  • respect our task evaluation.

After we reached this agreement, the development process became much more productive. We had some disagreements later but, since we implemented writing down all the important points after each Zoom call, we solved those problems quickly.

Let’s start building your healthcare app today!

We can’t wait to hear your ideas. Contact us and get a free project estimation in 48 hours.

Start today

Coding and Diplomacy school

The project took us 8,000 hours. The service became available to users in the middle of April. The first partner switched several offline clients to the service and runs sessions in the app. Recently, the service got a new doctor — it doesn’t happen fast due to rigorous selection. At the moment of finishing our case study, the partner conducted 69 sessions and a new therapist did 2.

Our client is currently working on marketing and promotion. And we keep supporting the project — right now, we’re refining two intended features: 

• • a chatbot that helps users choose a therapist by asking questions and suggesting doctors’ profiles,
  • push notifications with reminders of upcoming sessions or new chat messages.

And to me, working on this service became a negotiation workshop and a source of insights on project management. We always work with clients because each app is their idea and they’re experts in their own fields. And we are experts in development, design, and usability. Sometimes, those expertise overlap — and that requires negotiations, management, and looking for a compromise.

You can find common ground with your client and come up with a solution if you follow these principles:

1. Write down agreements after every call.
2. Don’t be scared of omitting something. It’s impossible to include everything — but with a good team, you can quickly implement what’s lacking.
3. The main management pain point is third-party integrations. Discuss risks with your client — you can even invite them to the call with a third-party service representative.
4. If you feel uncomfortable, discuss this issue with your client and explain that micromanagement doesn’t work. Try to make your job as clear as possible — provide your client with daily and sprint reports.