Forem: Timotej

Building Limberly, Part 1: We're Not Moving Enough

Timotej — Sun, 29 Mar 2026 22:00:00 +0000

The health tax of desk work

I've been a software developer for over ten years, and I've spent most of this time sitting. Being aware of the general idea that "sitting is bad for you," I was going to the gym three times per week to counter the negative effects.

Despite working out, I occasionally experienced neck pain, shoulder pain, back pain, and forearm aches. Luckily not all at once, but taking turns. Some of it was obvious, like a stiff neck after a long day, but some was sneakier. For instance, sitting for long durations disengages your glutes¹, which makes something else compensate, which makes something else hurt. Your butt forgets how to butt, and your back pays for it.

After checking online, I learned that plenty of people were paying the same kind of "health tax" while working sedentary jobs, and they were looking for solutions.

Problem: Sedentary work causes significant strain on our bodies.

Everyone is a snowflake

There's no such thing as a perfect textbook body. Everyone comes with their own quirks, myself included. After working with personal trainers, I learned that my body has a few limitations, such as a hip impingement² and "flat feet."³Both of these were possible to improve, but three gym sessions a week weren't it.

I needed to do certain exercises at home every day. Homework, yikes. Sometimes I'd do them before work, sometimes after, but never really consistently. It just wasn't on my mind, or I felt like I didn't have time for it.

As a result, I spent a long time working around these limitations at the gym rather than addressing them directly.

Problem: Some of us need to be doing specific movements daily but either forget or feel like we don't have the time.

Can't buy your way out of it

Spend any time on the subreddit /r/ergonomics, and you'll notice a pattern. People are trying to undo what sitting all day does to them via standing desks, lumbar supports, ergonomic keyboards, footrests, etc.

I brought up this topic with my personal trainer, who works in rehabilitation and ergonomics alongside a team of experts and sees the consequences of desk work every day. He mentioned that one hard problem here is that people pay for a solution but tend to skip the actual work. This is exactly what I've noticed in my online research. People buy an ergonomic chair, a standing desk, or an exercise program, but they don't actually move.

Eventually some of these people show up at my PT's studio, paying a lot of money to fix what their ergonomic equipment was supposed to prevent - and they still end up having to put in the work!

Problem: People tend to overly rely on ergonomic equipment to offset negative effects of desk work.

A few minutes at a time

I don't remember where I first heard about them, but I'd been vaguely aware of micro-breaks for a while. Those short pauses where you purposefully step away from what you're doing, which apparently helps you recalibrate and focus on your task.

At one point, I dug deeper into the research behind them, and I was surprised by what I found. I learned that my desk job comes with a 16% increased all-cause mortality risk⁴ and that the main way to counter it comes down to moving and taking regular breaks during work. For maximum effect, the breaks are supposed to include light activity, not just switching the work-related browser window to your personal one⁵. Even so, just taking breaks and stepping away from work is a good first step⁶.

I realized I could use these short breaks to do my daily "homework," which I had struggled to schedule into my workday before.

Idea: Perform my required daily movements during micro-breaks. This ensures I always do them, I stay more engaged with my work, and I work on my longevity at the same time.

The best posture is your next posture

The above research⁴ also revealed another interesting finding: alternating between sitting and not sitting at work was not associated with a significant increase in mortality compared to mostly not sitting. Essentially, it's not that you need to stand all day; you just need to not sit all day.

Ergonomics research backs this up too: one study tested a protocol of 20 minutes sitting, 8 minutes standing, and 2 minutes walking, and it beat every other configuration (including standing-only) for reducing discomfort and fatigue⁵.

Idea: While working, alternate between sitting and standing. If a walking pad is available, it's worth using that too.

The low-tech solution

After gathering my learnings, I wanted to apply them to optimize my workday. There are multiple moving parts that need to come together to achieve that. We have the focus/break cycle, the posture switch cycle, and keeping track of the required daily movements (the homework).

My first instinct was to use a pen and paper plus my phone's timer app (or even those analog pomodoro timers). I tried setting this up, and it felt like a chore. Especially since every new addition adds a new thing to manually manage. I also assume not everyone has the knowledge and discipline to set this up, so it's not something I could share with my friends and colleagues.

Idea: There should be an automated system that combines ergonomic best practices and guides users on what to do and when.

The high-tech solution

After discarding the low-tech idea, I looked into a more appropriate 21st-century-style solution. Specialized apps that position themselves as a solution to the "sitting problem" do exist, but after trying a bunch of them, I found they come with caveats.

Some had decent exercise libraries, nice animated or video instructions, and Apple Health integration, but the core experience felt like an afterthought. They displayed what to do, but not why or when. They came across as home workout apps with a focus timer feature. On top of that, the ones I tested felt janky, required an account just to get started, and locked basic functionality behind a subscription.

That's why I decided to create Limberly.

Finally, the plug

Limberly is a mobile app that keeps you moving throughout the workday. On top of a focus timer and break activity suggestions, it implements mods (as in modifiers): small tweaks that mix up your sessions, like alternating your posture between sitting and standing.

At the time of writing this, I've been daily-driving it for about three months, starting from when it was nothing more than a basic timer. It works offline, doesn't require an account, and has no subscriptions.

If you'd like to try it yourself, go to limberly.app and join the waitlist. The app is still not publicly available, but I'll invite you to the testing group.

I'm a big fan of being able to pay rent and eat food, so some features may end up behind a paywall, but Limberly will always have a free, no-nonsense core.

Next up

This is the first post in a series about building Limberly. Here we focused mostly on what ignited the idea behind the app, while the next one will go over the tech stack and the architecture.

Thanks for taking the time to read this. Now, go get a glass of water, and do a couple of air squats :)

Footnotes

Prolonged sitting tightens the hip flexors and lengthens the glutes, a phenomenon colloquially known as dead butt syndrome. Without glute support, the load shifts to the lower back, hips, and knees, and they start hurting. ↩
Femoroacetabular impingement is a condition where the shape of the hip joint causes the bones to pinch against each other during movement. For me, avoiding the resulting pain means squatting with toes pointed further out, reaching less depth, and replacing conventional deadlifts with the sumo variation. Hip impingement is a spectrum, and I'm working on making the most of the range I have. ↩
What I thought my whole life were "flat feet" turned out to be collapsed arches, a condition where the arch drops over time from weakened muscles and tendons. Unlike true flat feet (pes planus), collapsed arches can often be significantly improved with targeted exercise. I like how this video explains it. ↩
In 2024, a study of 481,688 workers, tracked over 13 years, found that "individuals who predominantly engaged in sitting at work exhibited a higher risk of mortality from all causes (16%) and cardiovascular disease (34%) compared with those who predominantly did not sit, even after adjusting for sex, age, education, smoking, drinking, and body mass index." It also found that individuals engaging in very high levels of leisure physical activity, 90 or more minutes per day, effectively eliminated the elevated mortality risk. ↩ ↩²
A paper from 2022 found that active breaks involving light-intensity movement, around 2 to 3 minutes every 30 minutes, reduced musculoskeletal discomfort and improved cardiometabolic markers without negatively impacting productivity. One of the reviewed studies, Kar & Hedge (2020), tested a sit-stand-walk protocol, which outperformed all other configurations. ↩ ↩²
A meta-analysis from 2022 found statistically significant effects of micro-breaks on boosting vigor and reducing fatigue. The authors conclude that "any type of decoupling activity" is effective for well-being. ↩

6 Things Solo Developers Do to Make Development Take Forever

Timotej — Thu, 29 Jan 2026 00:00:00 +0000

Being a solo developer watching your project drag on longer than expected, you've probably wondered what's actually going on. I see the frustration in posts from devs online, and I think it's something a lot of us go through at some point in our careers.

Although it may feel like you bit off more than you can chew, it's not always a single point of failure that's causing your projects to stall and spike your anxiety levels.

Here are some things that you may be doing, intentionally or not, that might be contributing to development taking so long:

1. Pulling time estimates out of thin air

Have you ever looked at a seemingly simple project and thought: two months, maybe three? A year later, you're still working on it.

The problem isn't necessarily that you're slow. Absolute time estimates are pure fiction when you're building something you are not a domain expert in - and even then, unknown unknowns¹ will constantly surprise you.

It may very well be that your work velocity is fine, but your estimate was too optimistic. However, once you set over-optimistic estimates, you stress about hitting your made-up deadline. Then you don't even ship what you have because it doesn't match your initial vision.

Try this

If possible, stop with the hard deadlines. Track relative progress instead. Did you move forward this week compared to last week? How does the effort and complexity of this feature compare to that other feature? This gives you relative estimates. These will probably still be off (unknown unknowns, remember?), but they'll be way less off than magical absolute deadlines.

For tracking project progress, I like using Kanban. You move cards from TODO to Doing to Done. You can estimate how cards relate to one another (task A seems like more effort than task B), but you don't slap fabricated deadlines on them.

2. Choosing your tech stack based on popularity and trends

What works for a team of 50, 100, and 1000+ developers at a VC-funded startup won't necessarily work for you; but you'll be sure to hear about it at every meetup, conference, and online forum.

This is especially true within the "fullstack JavaScript" ecosystem, where a hot new framework emerges every couple of months. Something I've heard before: "by the time I'm done, a new version of all my tech stack will be released."

When you use a tech stack just because it's trendy, you quickly find out that what works for others does not necessarily work for you. You end up fighting against the tech stack and feeling anxious because you're not productive with the tools that random online posters claim make them print money and singlehandedly saved their marriage.

Try this

Pick tools that make you productive. This does involve investing time to find your perfect toolset, but it will pay itself off many times over the years. Being a solo dev usually means you have a lot of flexibility in picking the tooling that you want. You probably don't let others tell you what size of shoes to wear, so do the same for your tech stack. To continue the shoe analogy: walk around in your tech stack for a bit, and see if it fits.

For me, the stack for most web projects is Elixir, Phoenix, and SQLite. It's stable, it lets me move fast, and since SQLite is embedded, I don't need to maintain a separate database server. This stack is optimized for dev happiness, saving money, and reducing headaches - for me.

3. Obsessing over scalability

Being a solo builder means you've got to be prepared for everything, including overnight success and enormous traffic spikes. That's what we love to imagine: "What if the thing I'm building becomes so successful that it collapses, and I'm unable to restore it?"

This fear is sometimes even stronger than the fear of not having a single user! To deal with it, we tend to over-engineer the simple things... you know, just in case.

What's your realistic expected traffic? Hundreds of users don't need infrastructure that handles millions. You probably don't need to clone Google's infrastructure setup, even though their marketing team would be delighted if you did. The time you spend tinkering with Redis, sharding your database, setting up microservices, and multi-region deployments could be spent on developing things that your users care about today.

Try this

Build for your actual needs, not your fantasy launch day. You can scale when you need to. In most cases, it's easier and cheaper to start simple and make it scale later.

I have one VPS at Hetzner running Dokku. All my projects live there. The stack I use is light and performant enough that I don't need the complexity of AWS, and I save on hosting. If traffic ever becomes a problem, I switch to a beefier VPS.

4. Focusing on too many tangents

Sometimes you're learning a new technology as you work on your project, or you decide that it's worth developing something in-house instead of using an off-the-shelf solution. You will naturally be slower and less efficient. This is fine and expected, but it is important to be realistic about what it means in terms of progressing the core functionality of the product you're working on.

To use a bit of gaming terminology, the more side quests you take on, the slower you progress on the main quest.

Try this

Be mindful about your tangents. If you decide to use a project as an opportunity to use that new programming language you just learned, don't also use a database you're not already comfortable with, a new deployment method, etc.

I write down and clearly tag my project's side quests so that it becomes immediately obvious when I'm starting to focus on the wrong thing. It's usually not difficult to get back on track, but first you have to realize you've strayed off course.

5. Finding new things to add before shipping

This one kills projects. You're nearly done but you keep finding cool new things to add. You've told your friends about what you're building and they've got some interesting suggestions that you want to implement. Also, things look a bit barebones; surely you've got to perfect all the tiny details before the big launch, right? By doing this, you're essentially perpetually moving the finish line. Shipping a minimal product tomorrow is better than never shipping a perfect product.

Try this

After the initial research and requirements gathering, write down the exact features your MVP² will include. Everything else goes in a "nice to have" list that you ignore until after you ship. Forget about the new features you just dreamed up, even if they seem more exciting to implement. Ship it now, perfect it later. Small, consistent improvements beat stressing over a perfect, big release.

I like to keep the 80-20³ rule in mind. With a minimum amount of work, you can ship a thing that users can already start using and give you feedback on; getting feedback early means you can focus on the stuff that actually matters to your users.

6. Neglecting your health

Being in the zone⁴ is awesome, and at times you don't dare move out of your chair because you're afraid of breaking that flow. However, your body needs maintenance, and it rewards you for it. How many times have you found a solution to a mind-boggling problem while not actively solving it? On a walk or in the shower; you weren't focused on the task at all! It might feel counter-productive at first, but you can actually perform better by not working for a couple of minutes (taking a break).

There's research on this! A 2022 paper found that taking micro-breaks boosts vigor (your "energy") and reduces fatigue (your "tiredness"). Another study from 2022 reports that active micro-breaks every 30 minutes reduce discomfort in office workers with no productivity loss.

Try this

Take small breaks every 30 minutes. Sometimes you're too busy; that's fine, but try not to skip 2 breaks in a row. Drink lots of water. Adjust your workspace ergonomically to minimize the risk of injury. Change your posture (e.g., from sitting to standing) often. Get enough sleep. The small stuff compounds and helps you feel more energized. More energy means you can work on the project without feeling like you got hit by a bus. It's a marathon, not a sprint (get it?).

Although a bit clunky, I use my phone's timers to work in pomodoro-like focus sessions. I also use it to remind myself to drink water. If working from home, I also try to air out my workspace, and during breaks, I get on the floor and do some simple bodyweight exercises.

Final thoughts

Solo devs tend to work harder when they should work smarter. You're not a crappy developer for not shipping fast enough. You're probably just fighting yourself by incorrectly defining what "fast enough" means, not investing time to figure out which tools you excel with, focusing on too many tangents, and by not allowing your body and mind to recover.

Footnotes

Unknown unknowns are variables that we cannot expect because we don't know what they are yet. ↩
Minimum viable product. A barebones product with just enough features that you can give it to your users and start gathering feedback. ↩
Also known as the Pareto principle. It can be simplified as roughly 80% of outcomes result from roughly 20% of causes. In other words, 80% of your product comes from 20% of your effort. ↩
Being in the zone means being fully focused on a specific task. ↩

Confident Technical Decisions

Timotej — Mon, 08 Dec 2025 00:00:00 +0000

I recently came across a post from a solo developer who captured something I've also struggled with in the past:

I'm literally the only tech person here and I'm overwhelmed by decisions.

Migrate the frontend to Next.js? Astro? TanStack Start?

Backend to Nest.js? Or ditch Node for Go?

Is MongoDB still fine? Or should I chase down PostgreSQL?

Isn't it a horrible feeling?

Being a solo developer and having no one to bounce ideas off. You're alone with fifty different opinions from the internet and no way to know which one is right for your situation.

Every decision feels like a fork in the road with tons of rabbit holes. You're full of self-doubt, and you end up procrastinating instead of focusing on what you should be doing - building. Every decision you make, you second-guess:

"Worried Cloudinary might get expensive if traffic spikes: should I plan on switching to Bunny CDN + S3"
"I really like the ease of Netlify and Render, but is it worth learning something else? Is it future-proof?"

You waste time digging through online discussions confirming your opinions, while life moves on and new business requirements pile up. Not only that, but new tech gets released, and little by little, you feel like you're getting crushed under a pile of decisions.

The way out

Imagine confidently making technical decisions, knowing it's the right choice for your use case, and moving on without second-guessing yourself.

No more searching through forums for an opinion that matches yours just to feel a sense of calmness. No more wondering if you're falling behind because you haven't adopted the latest framework. You make the call, close the tab, and get back to your project - your project that works and gets you paid.

Here's the thing: Most of the time, the tech is fine as is. The reason you're suffocating is that you're unsure of what you're actually trying to achieve. That uncertainty is what makes you over-engineer solutions and second-guess your decisions.

Sure, the fancy frameworks and tools from Meta and Google have great marketing. All the tech YouTubers are talking about them! However, if you know exactly what outcomes you are trying to achieve, and you scrutinize your technical decisions with these outcomes in mind, it becomes much easier to dismiss things you clearly don't need and focus on the things you do.

Know your outcomes

Before you can evaluate any technical decision, you need to know what your software exists to do. Not the features - the outcomes. What are you enabling for your users?

Letting busy people order groceries online
Allowing gym-goers access via an electronic card or mobile app
Helping surfers check conditions before heading out
<Insert the thing(s) your business does and customers pay for>

Write them down. Keep them visible. They're the foundation for every decision.

The filter

When making the next decision, hold it up against your outcomes and ask:

1. Does this serve my outcomes?

Not "is this cool" or "is this best practice" - does it directly enable what I'm trying to achieve? If not, don't add it, don't rewrite it, and don't touch it.

Your users don't care if you use Postgres, SQLite, or MongoDB. Stick with what you have until it becomes a bottleneck for your company.

Is rewriting your app to have a cleaner architecture worth it? Only you can tell - are you losing customers over it? Are you experiencing weird bugs all the time? Then maybe. Do you find it personally ugly or just not that exciting? Don't touch it.

2. Does this make things simpler or more complex?

Every tool you add can break, change pricing, get deprecated, or need configuration you'll forget. Is the benefit worth that cost?

Always pick the simplest solution. Sometimes this means getting an off-the-shelf product instead of building it in-house. There is more up-front cost, but your time as a developer costs money too.

Sometimes the cleanest code is no code.

3. Am I solving a problem I actually have?

Not one you might have someday. Not one a blog post warned you about. A real problem, happening now.

Is your traffic high enough to warrant the added complexity of a CDN? Do you really need a data lake right now?

When in doubt: choose simpler. You can always add complexity later. Removing it is much harder. Start small, start unscalable, and filter out the noise. Grow with your product.

Your one action

Before you spiral on another decision, do this:

Write down your top 1-3 outcomes. Not features. Not technical goals. What is your software actually trying to enable? Put the list somewhere visible.

The next time you're drowning in options for a decision you can't seem to make, go through the filter. Use your best judgement, make the decision, and move on.

When your decision is guided by outcomes, you can always justify making it.