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. Specifically 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:

See the reminder. Tap the button. 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.

It is an example of something we believe strongly at Keystone Foundry: 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 doesn’t 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 isn’t right.

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

They don’t need to understand the commercial relationship behind the app. They shouldn’t have to configure complex settings. And they certainly shouldn’t 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 bit.

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 creates and tracks invitations securely, 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 different operating systems, two application ecosystems, different notification services, different device behaviours, different submission requirements and different 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.

That distinction matters.

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.

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.

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.

And for an application whose central proposition is simplicity, asking somebody to invent and remember yet another password works against the product.

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

The user experiences a straightforward verification process.

Behind it sits token management, expiry, validation and secure API authentication.

Again, the complexity belongs in the platform rather than in front of the person using it.

Notifications are part of the product, not an afterthought

DailyOK relies on something every mobile developer quickly discovers is considerably harder than it looks:

Notifications need to arrive at 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 boringly reliable, 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 isn’t 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 doesn’t.

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.This is an important product distinction.

DailyOK isn’t 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.

More importantly, it 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 doesn’t need to become a surveillance system in order 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 that approach: 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 aren’t glamorous features.

They 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, isn’t conceptually creating a new DailyOK identity.

The device has changed.

The relationship hasn’t.

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 entire 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 a product somebody can actually download.

Keystone Foundry has taken DailyOK through that process on both ecosystems.

That means handling the development and technical architecture as well as the decidedly less glamorous work required to turn development builds into distributable applications.

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

It is all part of delivering the product.

DailyOK isn’t 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 isn’t any particular technology.

It’s what we deliberately chose not to expose.

A great deal happens when somebody taps that button.

• There is a mobile interface.
• There is authentication.
• There is an API request.
• There is a relationship between accounts.
• There is a scheduled check-in.
• There is a database transaction.
• There is state.
• There may subsequently be notification logic and escalation.

The person tapping the button needs to know none of this.

They just need to know:

I’m OK.

That is the point.

The technical sophistication of DailyOK exists specifically so the user experience doesn’t have to feel sophisticated.

More than app development

DailyOK demonstrates the breadth of work Keystone Foundry can bring to a digital product.

We haven’t 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:

Those are product questions, UX questions, commercial questions and engineering questions.

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 doesn’t want to spend their life proving it.

A tiny daily interaction creates that reassurance.

IOS Carer & Caree

Android Carer

Android Caree

The complexity is there.

The user simply doesn’t have to see it.

And that’s exactly how we wanted to build it.