SealedMSG - message that can save life

The situation

The idea for SealedMSG came from a digital nomad community in Bali.

The starting point was simple: people sometimes carry important information that other people would need if they suddenly became unreachable. That information can be personal, practical, or business-related. Instructions. Important details. Information someone else may need to act on.

The problem is not necessarily that people do not want to prepare this information. The problem is that there is no simple mechanism connecting "I am still here" with "if I stop responding, this information should reach the right person."

SealedMSG was created around that mechanism. A user creates an account, prepares messages, chooses trusted contacts, and defines a check-in schedule. If the user stops checking in, the system goes through a sequence of safeguards before delivering the relevant messages.

We kept the intended product deliberately narrower than a digital vault or legal service. The user writes the information. SealedMSG manages the delivery condition. Recipients do not need to create an account to receive a message.

The challenge

The technically interesting part of SealedMSG was not building a particularly complex application. It was deciding when the system was actually allowed to act.

A missed check-in does not necessarily mean that something has happened to the user. Someone can forget, lose their phone, travel somewhere without connectivity, or simply miss a notification. Sending a prepared message too early can be a serious mistake. At the same time, a system that waits indefinitely defeats its purpose.

That created a product and engineering problem around the sequence of events: Missed check-in → reminder → grace period → cancellation opportunity → message delivery

The system needed more than a simple if user missed check-in, send message rule. There are multiple case-specific situations in the application, each requiring its own logic around what happens before anything is delivered.

Decisions before code

The original product discussions contained considerably more functionality than we wanted in the first MVP. The non-technical co-founders had several ideas for additional functionality, including AI integration, message confirmation flows, and a Telegram bot.

We deliberately left those out.

Build the core mechanism first The MVP needed to prove one thing: Can a person configure a trusted message-delivery system that acts predictably when they stop checking in? Everything that did not directly support that mechanism could wait. That reduced the first version to the essential user journey rather than turning the MVP into a collection of future features.

No mobile app We did not build a native mobile application. The product could be delivered as a web application, making development faster and more predictable while covering the functionality required for the MVP. If the product later needs a more app-like experience, a progressive web app (PWA) can be introduced without making the initial build unnecessarily complicated.

Recipients do not need an account The person receiving a message should not have to become a SealedMSG user first. The sender chooses the recipient and the message. The recipient receives the information through the supported delivery channel directly. This positions the product strictly as a message delivery system, removing onboarding friction for the end-user's loved ones.

Keep the safety mechanism explicit The system does not immediately act on one missed check-in. There is a chain of actions designed to provide opportunities to confirm that everything is still fine before a message is delivered. The cancellation period is therefore not an optional extra feature. It is the core of the product's trust logic.

Don't solve future problems in the MVP AI, Telegram automation, and complex confirmation mechanisms were left for later. The goal was to get the core product live in two sprints, validate the concept, and leave room to extend it based on actual market feedback.

How it works

1. Write: The user prepares the messages they want trusted contacts to receive if they become unreachable. The information is strictly written by the user rather than automatically scraped from other accounts.

2. Choose the recipients: The user selects the trusted people who should receive specific messages. Recipients do not need their own SealedMSG account.

3. Set the check-in schedule: The user decides how often they need to confirm that they are active (daily, weekly, monthly).

4. Missed check-in: If the expected check-in does not happen, the system does not immediately release anything. The first stage is a multi-channel reminder.

5. Grace period: If the silence continues, a grace period begins. The user still has an opportunity to cancel the process while the messages are queued for possible delivery.

6. Execute: Only when all conditions have been satisfied does the system deliver the selected messages. If the user returns during the cancellation period, the execution aborts.

The most important part of this architecture is not the individual notification, it is the airtight chain of conditions between a missed check-in and an actual message delivery.

The build

The MVP was built from scratch in four weeks, across two two-week development sprints, starting in March 2026.

The team consisted of:

• 1 CTO

• 1 Developer

• 1 Designer

The first sprint established the product foundation and core application structure (UX design, PostgreSQL database modeling, Directus API backend).

The second sprint brought the complete user flow together, including the Next.js web application, authentication, check-in mechanism, delivery logic, third-party communication integrations (AWS SES, WhatsApp, SMS), and the Stripe payment flow.

The architecture was designed jointly by the CTO and software developer. The focus was to create a small, predictable system that could be delivered within the two-sprint constraint without introducing scope creep.

Release and validation

The MVP was completed at the end of the two-sprint development period and made publicly accessible. The $25 lifetime pre-sale flow is fully operational.

At this stage, further customer acquisition and commercial validation are being handled by the founding team. The important technical milestone was reached: the original idea became a working, secure public product in just two development sprints. The system is now capable of running the core SealedMSG workflow in real conditions rather than simply demonstrating it as a prototype.

Outcome

SealedMSG went from idea to a working, publicly accessible MVP in four weeks. The delivered product includes the complete core flow: account → messages → trusted contacts → check-in → reminders → grace period → cancellation opportunity → delivery.

The project intentionally does not claim that the business has already achieved product-market fit. Those are the next stages of validation. What we delivered was the absolute technical foundation required to test the idea with real users and securely process pre-sale revenue.

Why this is a techlead.fit case study

SealedMSG is a perfect example of the difference between building everything people can imagine and building the exact system a business needs to validate its idea.

The initial discussions contained significantly more functionality than the MVP required. We reduced the scope. We did not build AI integration. We did not build a Telegram bot. We did not build a mobile application.

Instead, we concentrated the four-week development effort on the core product mechanism and the predictable logic required to make a "dead man's switch" fail-proof. The most important decisions were made before the code was written.

The result was not a bloated application. It was a working product launched and tested with real users after just two sprints.

• Understand the product.

• Reduce the scope.

• Define the critical logic.

• Build the smallest complete system.

• Launch it.

• Then learn what deserves to be built next.

Need to turn an idea into a working MVP?

The difficult part of an MVP is rarely writing the first line of code. It is deciding what the first version actually needs to prove, what can wait, and what technical decisions will allow the product to reach users without unnecessary complexity.

At techlead.fit, we help founders turn product ideas into technical roadmaps, define the MVP, make the architecture decisions, and take the product through development.

Relevant services: Technical Audit · CTO Sprint · MVP Build