DailyOK — Turning a Simple Idea into a Complete Cross-Platform Product

The Case Study in Brief

Some of the best technology products begin with a problem that can be explained in a sentence.

Is somebody I care about OK today?

For families with an older parent living independently, parents with children or teenagers away from home, carers, or simply people separated from somebody they care about, a missed phone call can quickly become a source of anxiety.

At the same time, nobody wants to feel watched.

DailyOK bridges that gap with an intentionally lightweight daily check-in. At the appropriate time, the person being looked after receives a prompt. They confirm that everything is OK, and the person who cares about them gets reassurance without needing another phone call, message or intrusive piece of monitoring technology.

Behind that deliberately simple interaction, however, is a considerably more sophisticated product.

Keystone Foundry has been responsible for turning DailyOK from a product concept into a complete digital platform: designing its user experience, developing the central API and infrastructure, building the mobile applications for both iOS and Android, and solving the practical challenges involved in authentication, invitations, notifications, account management and cross-platform delivery.

The Challenge

Starting with the Problem, Not the Technology

The fundamental product decision behind DailyOK was that it had to feel almost effortless.

It would have been easy to build something packed with dashboards, configuration screens and features. That would also have missed the point.

For the person completing the check-in, DailyOK needed to require almost no technical knowledge at all. The interaction should be:

1. See the reminder.
2. Tap the button.
3. Carry on with your day.

That philosophy influenced almost every technical and design decision we made. Rather than expecting every user to understand accounts, subscriptions and configuration, DailyOK separates the people managing the relationship from the people simply being asked to check in.

The person setting up DailyOK can create and manage the relationship, while their loved one can join using a simple invitation process. That removes friction exactly where it matters most.

Good software is not software that exposes everything it can do. Good software makes complicated things feel simple.

1/ Product Strategy

Designing Two Very Different User Experiences

One of the most important pieces of product thinking was recognising that DailyOK does not really have one type of user. It has two.

The first is the person arranging and managing the check-in, perhaps an adult child looking out for an elderly parent. They need control. They need to add people, manage schedules, understand whether somebody has checked in and respond appropriately when something is not right.

The second is the loved one receiving the check-in. They need almost none of that.

They do not need to understand the commercial relationship behind the app. They should not have to configure complex settings. And they certainly should not need somebody standing beside them explaining how the software works.

That resulted in a deliberately asymmetric user experience. The management side can contain the tools necessary to manage the relationship, while the check-in experience can remain extraordinarily simple.

It sounds obvious once it exists. Getting to that simplicity is the difficult part.

Making Onboarding Almost Disappear

Account creation is frequently where otherwise good applications lose users. With DailyOK, we deliberately designed around the path of least resistance.

A person setting up DailyOK needs only the information genuinely required to establish the relationship. The loved one can then be invited into it rather than being expected to independently navigate a conventional registration process.

Behind the scenes, DailyOK securely creates and tracks invitations, associates them with the correct accounts and generates invitation codes that allow the mobile application to establish the relationship.

Verification provides confidence that the person joining is the intended recipient without turning onboarding into an identity-verification exercise.

It is a small part of the visible application. Architecturally, it required considerably more thought.

One Product, Two Mobile Platforms

DailyOK is available on Apple iOS and Android.

From a customer’s point of view, that simply means they can install the app on their phone. From a development point of view, it means dealing with two operating systems, two application ecosystems, different notification services, device behaviours, submission requirements and commercial platforms.

Our job was to prevent any of that complexity from becoming the user’s problem.

Both applications communicate with a shared DailyOK platform, giving us one authoritative source for users, relationships, invitations, schedules and check-ins rather than creating independent islands of data on each device.

The phone is an interface to DailyOK. It is not DailyOK itself.

A user can change their phone without losing the relationships and information behind their account, and the core product is not dependent on one mobile platform. That also gives DailyOK a foundation that can evolve independently of Apple or Google.

2/ Backend Architecture

A Platform Behind the Apps

At the heart of DailyOK is a bespoke Laravel-based API and application backend developed by Keystone Foundry.

Rather than putting critical business logic into the individual mobile apps, the platform maintains the central state of the system:

• Users and their accounts.
• Relationships between the person managing DailyOK and the people they care about.
• Invitations and their current status.
• Check-in schedules and completed check-ins.
• Devices registered to each account.

It provides the secure interfaces through which the iOS and Android applications interact with that information.

This creates a much stronger architecture than simply building two standalone apps. Changes to core product behaviour can be implemented centrally. Information remains consistent across devices. Administration and support become practical. Additional clients or interfaces can be added later without redesigning the entire product.

The result is not simply an app. DailyOK is a software platform with mobile apps built on top of it.

3/ User Experience

Modelling Relationships Rather Than Just Users

One of the less visible but more important engineering challenges was the data model behind DailyOK. A conventional application might simply have a table of users. DailyOK needs to understand relationships.

• A person may look after more than one loved one.
• A loved one needs to be securely associated with the person who invited them.
• An invitation can exist before the recipient has completed registration, and that invitation has a state.
• Check-ins belong to relationships and schedules.
• Devices belong to users and must receive the appropriate notifications.

Those requirements informed a backend model covering accounts, loved ones, relationships, invitations, schedules, check-ins, registered devices and authentication.

Designing those relationships properly at the beginning means the application can grow without its data model becoming the thing that prevents it from doing so.

Secure Authentication Without Unnecessary Passwords

DailyOK also required us to think carefully about authentication.

The target audience makes conventional username-and-password authentication particularly unattractive. Passwords are forgotten. Passwords are reused. Passwords create support calls. For an application whose central proposition is simplicity, asking somebody to invent and remember another password works against the product.

Instead, DailyOK’s architecture supports verification through short-lived codes and secure application tokens.

The API can authenticate a person, verify ownership of the appropriate contact method and then issue the mobile application with the credentials it needs to communicate securely.

The user experiences a straightforward verification process. Behind it sits token management, expiry, validation and secure API authentication. The complexity belongs in the platform rather than in front of the person using it.

Notifications Are Part of the Product

DailyOK relies on something every mobile developer quickly discovers is considerably harder than it looks: notifications need to arrive for the right person, on the right device, at the right time.

A scheduled check-in is useful only when the person remembers to complete it. DailyOK therefore needed notification handling to be considered as a core part of the architecture rather than added at the end.

The backend maintains registered devices and provides the central logic necessary to drive mobile notifications across both platforms. That means accommodating Apple’s and Google’s different push-notification ecosystems while presenting one consistent DailyOK experience to the user.

The same architecture provides the foundation for more sophisticated workflows around reminders and missed check-ins.

The engineering goal throughout was simple: make the visible interaction reliably uneventful, however complicated the machinery behind it needs to be.

Building an Escalation Path

A check-in application is easy when somebody presses the button. But DailyOK is not designed around the button alone. The wider platform needs to understand whether a check-in was expected, whether it occurred and what should happen when it does not.

That requires server-side schedules rather than relying entirely on something running locally on a person’s phone. It means recording completed check-ins centrally and identifying outstanding ones. It creates the framework through which reminders and alerts can be escalated appropriately.

DailyOK is not simply a daily alarm with a green button attached. It is a platform that understands the state of a check-in.

SMS and Communication Infrastructure

We also developed integration between DailyOK and external messaging infrastructure where the product requires communication outside the app itself.

That includes integration with an SMS provider through the DailyOK backend, allowing messages and verification codes to be generated centrally rather than embedding third-party service credentials inside a mobile application.

Those credentials remain on infrastructure controlled by the platform. The mobile applications simply request the operation through the authenticated API.

It is both cleaner engineering and better security. It also makes communication services replaceable. An underlying supplier can change without requiring DailyOK’s users to understand, or ideally even notice, that anything has changed.

Privacy by Design

Building software involving families and personal wellbeing creates responsibilities beyond making the software technically functional.

DailyOK therefore had to be designed with a clear understanding of what information it genuinely needs. The product does not need to become a surveillance system to provide reassurance.

That distinction shaped both the proposition and the architecture. A loved one’s simple confirmation can provide the information somebody cares about without requiring continuous observation of their life.

DailyOK’s public product proposition deliberately emphasises reassurance rather than surveillance, including an absence of location tracking in its current offering.

We also built proper account lifecycle processes into the service. Users can verify ownership of an account and request deletion through a dedicated process, with short-lived verification credentials protecting what is necessarily a destructive operation.

These are examples of the engineering required to turn an application into a responsible production service.

4/ Cross-Platform Production

Designing for Change

Another significant architectural decision was keeping the core DailyOK service independent of either mobile ecosystem.

It would have been possible to build around services specific to Apple and then solve Android later. Instead, the system was designed around a common backend.

That gives DailyOK portability. A person moving from iPhone to Android, or vice versa, is not conceptually creating a new DailyOK identity. The device has changed. The relationship has not.

It also gives the product somewhere to grow. A web interface, additional administration tools, integrations or new device types can all ultimately communicate with the same central platform.

That is the difference between solving today’s screen and designing tomorrow’s product.

From Development Build to Real App Stores

Shipping mobile software adds another discipline beyond writing code. Both Apple and Google impose requirements around application metadata, privacy, account management, subscriptions, testing, signing and distribution.

A product can work perfectly on a developer’s phone and still be a considerable distance from being something somebody can actually download.

Keystone Foundry has taken DailyOK through that process on both ecosystems, including:

• Certificates and application identifiers.
• Signing and provisioning.
• Release builds.
• Store configuration.
• Privacy requirements.
• Testing, submission and updates.

It also occasionally means deciphering exactly what Apple or Google means when an automated system rejects something that appears entirely reasonable.

DailyOK is not a prototype sitting in a development environment. It is a real cross-platform mobile application delivered through the same channels as the world’s largest consumer apps.

Engineering the Commercial Product Too

A production application also needs to understand that customers, subscriptions and application-store accounts exist.

The commercial side of a mobile product is tightly intertwined with its engineering. Apple and Google each have their own purchasing infrastructure and subscription lifecycle. The application needs to understand which capabilities a customer is entitled to without putting billing complexity in front of the loved one simply completing their daily check-in.

DailyOK’s current service is distributed through the mobile app ecosystems, with subscriptions handled through Apple or Google rather than asking users to provide payment details directly to DailyOK.

That separation is another example of the underlying product philosophy: the right user sees the right complexity.

5/ Simplicity Within Use

Building for the Person Who Finds Technology Difficult

Perhaps the most interesting part of DailyOK is not any particular technology. It is what we deliberately chose not to expose.

A great deal happens when somebody taps that button:

• A mobile interface handles the interaction.
• The user is authenticated.
• An API request is made.
• Accounts are connected through a relationship.
• A scheduled check-in is found.
• A database transaction records its state.
• Notification and escalation logic may subsequently run.

The person tapping the button needs to know none of this. They just need to know: I’m OK.

The technical sophistication of DailyOK exists specifically so the user experience does not have to feel sophisticated.

More Than App Development

DailyOK demonstrates the breadth of work Keystone Foundry can bring to a digital product. We have not simply been handed a set of screens and asked to turn them into code.

Our involvement has covered the questions that exist before and around the code:

• Product: What should the product do? How should authentication and account deletion be handled safely?
• User experience: Where will people struggle? How can onboarding be easier and notifications dependable?
• Commercial: Who are the different users? What information needs collecting? How should accounts be related?
• Engineering: What belongs on the device and what belongs on the server? How can two mobile platforms be supported without building disconnected products? How should the architecture support what DailyOK might become next?

For us, they are all part of building the same thing.

Case Study Outcomes

The Result

DailyOK takes an emotionally important problem and gives it an intentionally uncomplicated answer.

One person wants to know that somebody they care about is alright. The other person does not want to spend their life proving it. A tiny daily interaction creates that reassurance.

iOS Carer & Caree

Android Carer

Android Caree

Behind it is a complete cross-platform product engineered by Keystone Foundry: iOS and Android applications, a central Laravel API, secure authentication, relationship and invitation management, scheduled check-ins, device and notification infrastructure, SMS integration, privacy and account-management workflows, and the architecture needed to take the product beyond its first release.

The complexity is there. The user simply does not have to see it.

That is exactly how we wanted to build it.