What I Underestimated While Building KAVYLO

Building a fitness app is much more than writing code

When I started building KAVYLO, I knew creating a fitness app would take time.

What I underestimated was how much of that time would have very little to do with writing the actual feature.

A feature might begin with a fairly simple idea: add training plans, improve workout tracking, create a new coaching function or connect another part of the app.

But getting from that idea to something that actually feels finished involves much more.

There is the interface, the data behind it, testing, edge cases, translations, navigation, accessibility, App Store requirements, website content and everything that needs to continue working after the feature is released.

That has probably been one of the biggest lessons from building KAVYLO.

Every feature creates work around the feature

It is easy to think about a new feature as one screen or one function.

In practice, almost every addition affects several other parts of the product.

A new training feature might also require:

• changes to navigation
• new database structures
• additional settings
• new empty and error states
• testing across different situations
• updates to the website
• translations
• support content
• analytics or progress views
• changes to other connected features

The visible feature is often only a small part of the total work.

This became even more noticeable as KAVYLO grew beyond a simple workout tracker.

Training, Nutrition, Recovery, Progress, Apple Health, Apple Watch, coaching, community and other areas all need to work as parts of the same product.

You can learn more about the broader product structure on the KAVYLO features page.

Keeping a growing fitness app understandable is difficult

Another thing I underestimated was how difficult it is to add more functionality without making an app feel more complicated.

Adding features is relatively easy compared with deciding where those features should live.

As KAVYLO became larger, information architecture became much more important.

Not every function should have the same visual priority.

Not everything needs to be visible on the first screen.

A product can have a lot of functionality and still feel simple, but only if the structure makes sense.

That means repeatedly asking questions such as:

• What does someone need to see first?
• Which functions belong together?
• What should move into a deeper screen?
• Which information is useful right now?
• Which information can wait until the user actively looks for it?

I have learned that simplifying a product does not always mean removing functionality.

Sometimes it means showing the right functionality at the right moment.

Training plans are a good example

Training plans sound like a clearly defined feature.

But a useful training-plan experience quickly connects to much more.

There are the plans themselves, exercises, workout history, upcoming sessions, different sports, progress and the question of how all of this fits into the rest of the app.

That is why I do not want KAVYLO to treat a training plan as an isolated list of workouts.

The goal is to connect planning with the training someone actually completes and with the wider fitness context around it.

You can see more about this on the KAVYLO Training Plan page.

The invisible work takes a surprising amount of time

Some of the work that takes the longest is work that users may never consciously notice.

A button needs to behave correctly.

A page should not break on a smaller screen.

A translated sentence needs enough space.

A loading state needs to make sense.

An empty screen needs to explain what happens next.

A user should be able to understand where they are without thinking about the navigation.

None of these things are particularly exciting on their own.

Together, however, they determine whether an app feels polished or unfinished.

I underestimated how much time I would spend on exactly this kind of work.

Localization is more than translating text

KAVYLO is now available in multiple languages.

At first, localization can sound straightforward: translate the text and add a language selector.

In reality, it affects many parts of a product.

Text lengths change.

Navigation labels change.

SEO pages need their own titles, descriptions and URLs.

Blog articles need localized versions.

Some terms should be translated while others are part of the product language.

And every language needs to remain consistent as the product changes.

The work does not end when the first translation is finished.

Every future feature has to fit into that system as well.

That was another area where the long-term effort was much larger than I initially expected.

Publishing an app does not mean it is finished

Before building KAVYLO, it was easy to imagine the App Store release as a finish line.

It is not.

Publishing creates a different kind of work.

Real people use the app differently than I do while developing it.

They notice things I have stopped noticing because I have seen the same interface hundreds of times.

A feature that feels obvious to me may not be obvious to someone opening KAVYLO for the first time.

That feedback is important because it changes how I think about the product.

The goal is not to react to every individual comment by immediately changing everything.

It is to understand what the feedback reveals about the underlying experience.

User feedback changed how I think about complexity

One particularly important lesson has been that a feature-rich product can quickly feel overwhelming.

KAVYLO covers several parts of fitness, which is intentional.

I do not want to solve that problem simply by removing useful functionality.

Instead, I have become much more focused on visible complexity.

The question is no longer only:

“What else can KAVYLO do?”

It is also:

“How can KAVYLO do more without making the user think about more?”

That affects the Training area, Today, Nutrition, Progress, Community and the way new functionality is introduced.

Building alone changes how I prioritize

I build KAVYLO independently.

That gives me a lot of freedom because I can make product decisions quickly and keep a clear idea of what KAVYLO should become.

But it also means every area competes for the same limited time.

Development, design, testing, content, localization, support, the website, App Store work and future planning all have to be prioritized.

I cannot treat every idea as equally urgent.

Learning what not to build immediately has become just as important as deciding what to build next.

I wrote more about how I manage KAVYLO alongside the rest of my life in How I Build KAVYLO Alongside a Full-Time Job, University and Everyday Life.

A working feature is not the same as a finished feature

This is probably one of the most important distinctions I have learned.

A feature can technically work and still not be ready.

It may need clearer wording.

The hierarchy may be wrong.

The screen may contain too much information.

The empty state may be confusing.

The feature may work perfectly on my device but behave differently in another situation.

Building the first version is often only the beginning.

The refinement afterwards is what turns functionality into a product experience.

I underestimated how connected everything would become

The larger KAVYLO becomes, the fewer truly isolated features there are.

Training connects to Progress.

Training connects to Recovery.

Nutrition provides additional context.

Apple Health and Apple Watch contribute data.

Coaching can use information from several areas.

A change in one part of the app can therefore affect how another part should work.

That interconnectedness is one of the things I like most about building KAVYLO, but it also creates complexity behind the scenes.

The challenge is making that complexity useful without exposing all of it to the user.

What I would approach differently today

If I started again with what I know now, I would think about systems earlier.

Not only individual features, but the structures that need to support future features.

That includes:

• reusable components
• scalable content structures
• localization from the beginning
• clearer information architecture
• reusable admin tools
• consistent data models
• fewer one-off solutions

Some of these lessons have already changed the way I build KAVYLO.

For example, parts of the website that originally required individual code changes are now managed through reusable systems instead.

That makes adding future content much faster and reduces the risk of creating the same problem repeatedly.

What I have learned from building KAVYLO

Building KAVYLO has made me look at software very differently.

The visible product is only the surface.

Behind every screen are dozens of small decisions about structure, clarity, reliability and what should happen next.

I still have a long list of things I want to improve and build.

But I have also become much more deliberate about how new functionality becomes part of KAVYLO.

The goal is not to build the app with the most features.

It is to build a fitness app where training, nutrition, recovery, progress and the surrounding data work together in a way that actually feels useful.

And that has turned out to be much more complex, and much more interesting, than I expected when I started.