What Node-Based Tools Don’t Simplify

I started with a question about node-based tools and ended up building a budgeting application.

But, the budget tracker wasn’t the project.

The question was.

It started while I was exploring Opal, one of Google’s experiments for building workflows through connected nodes. As someone who naturally thinks visually, it immediately caught my attention. Instead of writing code line by line, you connect pieces together and watch a system take shape.

For a while, it felt exciting.

Then it started feeling limiting.

Every workflow followed the same pattern. Input. Process. Output.

One of my early experiments with node-based workflows. Flowing as Input — Process — Output

The more I experimented, the more I noticed what was missing. There was little room for loops, interconnected logic, or the messy relationships that exist inside real products. Everything felt linear, while most products I’ve worked on as a designer rarely are.

That observation led me down a rabbit hole.

If node-based systems are trying to simplify software creation, what are they actually simplifying?

And more importantly:

What does a real application look like underneath the interface?

Through design school, research projects, internships, and personal ventures, I’ve spent years understanding people, behaviours, journeys, and experiences. What I hadn’t explored as deeply was the layer where those decisions become a functioning product.

I could read about databases, architecture, APIs, and development workflows.

But reading about something and experiencing it are two very different things.

So I decided to build.

Not because I wanted to become a developer.

Because I wanted to understand the layers that sit between an idea and a working product.

Why a budget tracker?

Partly because I needed one.

Most budgeting apps I came across seemed determined to do everything except the one thing I wanted. They wanted me to invest, save, track goals, analyse spending patterns, and optimise my life.

I just wanted to know where my money was going.

But the choice was also intentional.

If the goal was to understand how applications are built, I needed something complex enough to expose real product challenges and simple enough to actually finish.

A budget tracker sat right in that sweet spot.

It had inputs, calculations, data storage, categories, dependencies, and user actions. More importantly, it was something I could test every day without needing hundreds of users.

This way the budget tracker was chosen as a vehicle, not the destination.

I wasn’t optimising for growth, engagement, or retention.

I was optimising for clarity.

Building as a way of understanding

I started with the experience I wanted for myself.

Add salary.

Create categories.

Track expenses.

See what remains.

Simple.

At least on paper.

Using Figma Make, I generated the first version of the application. From there, the process became a cycle of prompting, refining, testing, breaking things, and rebuilding them. Once the structure felt stable, I moved the code into Claude and started exploring what it would take to make the application run independently.

The designed application

One decision I made early was to keep it offline and locally hosted.

Not because cloud infrastructure wasn’t possible.

Because it wasn’t necessary.

The goal wasn’t to build a scalable fintech product. The goal was to learn.

The further I went, the more I realised applications are less like a collection of screens and more like a network of connected decisions.

A change in one place affects something else.

A new feature creates new conditions.

A simple interaction introduces unexpected dependencies.

For the first time, I wasn’t just designing an experience.

I was observing how experiences are held together.

Defining the boundaries

One thing building immediately taught me was that product development is largely an exercise in deciding what not to do.

The moment I started sharing the idea, possibilities multiplied.

Automatic transaction syncing.

Payment integrations.

Bank connections.

Savings goals.

AI-powered categorisation.

Every suggestion sounded useful.

Most of them probably were.

But every new idea pushed the project further away from the original question.

So I kept coming back to a single principle:

Can a user understand where their money is going?

If the answer was yes, the feature stayed.

If not, it waited.

The challenge wasn’t generating ideas.

The challenge was protecting the purpose of the experiment.

When assumptions meet reality

The first version worked.

Which felt great.

Then other people used it.

Which was even more valuable.

The feedback wasn’t about aesthetics.

It was about freedom.

People wanted to add categories later.

Move money between budgets.

Adjust decisions they had already made.

Handle shared expenses.

The application was behaving exactly as I had designed it to.

The issue was that my assumptions and other people’s realities didn’t always match.

Looking back, many of my decisions were built around certainty.

The application expected users to know their categories upfront.

To plan before they started.

To commit early.

Real behaviour turned out to be much more fluid.

What initially looked like requests for additional features revealed a deeper pattern.

People weren’t asking for more functionality.

They were asking for more control.

The ability to edit, adjust, revisit decisions, and shape the product around their own behaviour rather than mine.

That shifted how I thought about the problem.

The challenge wasn’t budgeting.

The challenge was flexibility.

The feature that taught me the most

At one point, I introduced group expenses.

It seemed straightforward.

It wasn’t.

A single feature opened the door to dozens of new questions.

Who paid?

Who owes whom?

Can expenses be edited later?

What happens when someone joins midway?

What happens when someone leaves?

What happens when the amount changes?

The feature existed.

The use case wasn’t fully solved.

And that distinction turned out to be important.

The experience taught me the difference between shipping functionality and supporting behaviour.

Group expenses technically worked.

But supporting the different ways people actually manage shared spending required a much deeper understanding of the problem.

It was my first real encounter with product complexity.

Not the kind that arrives through massive ideas.

The kind that quietly emerges through small decisions.

Returning to the original question

By the end of the experiment, I had learned a lot about how applications are structured.

But I also found myself returning to the question that started everything.

Can software creation become genuinely accessible to people who don’t come from a technical background?

Before building the budget tracker, I assumed the biggest challenge would be implementation.

Understanding how applications work.

How data moves.

How logic gets connected.

How systems are structured.

And while those things were challenging, they weren’t the biggest obstacle.

The bigger challenge was understanding the consequences of decisions.

Every feature introduced new edge cases.

Every assumption created constraints.

Every simplification introduced trade-offs.

What surprised me most was that much of the complexity wasn’t living in the code.

It was living in the product.

In defining behaviours.

In handling exceptions.

In deciding what should happen when reality doesn’t match the ideal flow.

That changed how I think about node-based systems.

The real scenario of how product making works

I now believe they can significantly lower the barrier to building software.

They can make implementation more approachable.

They can help non-coders create things that would previously have required engineering support.

But building applications and building products are not the same thing.

Node-based tools may simplify how software gets constructed.

They don’t automatically simplify the decisions required to make software useful.

The question I started with isn’t fully answered yet.

But my current belief is this:

The future of accessible software creation isn’t about removing complexity. It’s about helping people navigate complexity without needing to become professional developers.

And I think there’s still a lot of room to explore how node-based systems can do that better.

What I’d explore next

If I continued developing the application, my priorities would be less about adding features and more about increasing flexibility.

Removing the onboarding gate so users can enter the application without defining everything upfront.

Allowing categories to emerge over time rather than forcing them to be decided in advance.

Making group expenses adaptable to different behaviours and real-world scenarios.

Understanding whether budgeting is actually a category problem or a flexibility problem.

My current hypothesis is that people don’t struggle because they lack categories.

They struggle because financial planning changes constantly, while many tools expect certainty where uncertainty is normal.

What I took away

This project didn’t start with a budgeting problem.

It started with curiosity.

The budget tracker was simply the vehicle that allowed me to explore a much larger question.

Along the way, I gained a deeper appreciation for the layers that exist between an idea and a functioning product.

Not just interfaces and interactions, but also logic, dependencies, constraints, trade-offs, and system behaviour.

The application still has limitations.

There are features I would redesign.

Flows I would rethink.

Assumptions I would challenge.

And that’s exactly why I continue to value it.

Because every limitation points to another question worth exploring.

And for me, that’s usually where the most interesting work begins.