Hey,
I'm Andreas, the CTO of Helppy 👋
Helppy is on a mission to change elderly care. We make care personal, transparent and accessible to ****seniors and their families. On the tech side of things, we contribute to this by building a best-in-class platform with superior UX for all the parties involved: the seniors, their families, our Helppers, our operations team and some third parties.
This post is a brief walkthrough of our tech stack. Personally I think this is super exciting, so I encourage you to read on. Oh, and before you proceed - keep in mind that we are looking for new talent. If you’re curious, don't hesitate to drop me a message on LinkedIn or by email.
Our infrastructure is hosted on AWS. We use CDK and Typescript to deploy our EKS Kubernetes cluster located in Stockholm. At the moment the cluster is only running 2 services (our monolith backend and Metabase). This might seem like overkill, but with this setup we can easily replicate environments (e.g. test/staging), ensure high-availability and deploy new code gracefully. It also allows us to easily add new services in the future.
Our web frontends are deployed using Vercel. Connecting Vercel with Github gives a smooth dev experience and things like preview URLs for PRs comes without additional configuration.
Our backend is a Java application exposing an API (primarily GraphQL) to our frontends. Over the years, we've built a custom framework using libraries such as graphql-java and jOOQ which makes it convenient to build performant GraphQL APIs while still preserving the necessary flexibility. Our GraphQL schema is auto-generated from code and passed to the frontends for further processing and codegen (more on this below).
Most of the state stored by our Java application resides in a PostgreSQL database on Amazon RDS. Images and other files are stored in S3 and we also use a mix of other services for various use cases: SNS, Auth0, Libpixel, Datadog, Bugsnag, etc.
Our platform contains several web frontend apps (for seniors and family members, helppers, operations team, etc.). All of these apps are standalone Nextjs apps written in Typescript and heavily relying on shared code. We use a monorepo approach (npm workspace) where shared code can be used without strict package boundaries.