This week I published the first promo video for CLARIFYProperty. That was a big milestone — not because the product is “finished”, but because it marks a shift toward making the work more visible outside of day-to-day development. Take a look here https://www.youtube.com/watch?v=ghHfJFSXOek

With that done, I’ve been back in the Smart Schedules area, focusing on something deceptively simple: how users start creating one.

Where It Started

Originally, Smart Schedules had two entry points:

“New Rent Smart Schedule” “New Mortgage Smart Schedule”

It was straightforward, explicit, and worked well for the initial scope of the product.

But it also quietly introduced a limitation: every new schedule type would require yet another button.

That doesn’t scale well.

Even at a small scale, the UI starts to reflect implementation details rather than user intent. And over time, that becomes a bottleneck — both in the interface and in the underlying structure.

The First Attempt: A Single “New Smart Schedule” Button

The next step was to consolidate those two buttons into a single entry point.

A simple “New Smart Schedule” action made things cleaner, but it still hid an important problem: the system was treating “creating a schedule” as a single uniform process, when in reality it isn’t.

Different schedule types have different logic, different inputs, and potentially different future evolution paths.

So while the UI was cleaner, the structure was still subtly constrained.

The Current Approach: A Creation Flow

The latest change removes the idea of a single entry button altogether.

Instead, starting a Smart Schedule now begins a proper creation flow.

The first step presents users with a set of schedule type cards, where they explicitly choose what kind of Smart Schedule they want to create.

This replaces both:

• multiple hard-coded “New …” buttons
• and the single generic entry point

With something more flexible and more honest about what the system actually does.

Why This Matters

This isn’t just a UI change — it’s a structural one.

By introducing a typed selection step at the start of the flow, the system now assumes:

• Smart Schedules are a family of related but distinct features
• each type can evolve independently
• new types can be added without redesigning the entry point
• the creation flow can diverge early based on intent

In other words, the complexity is no longer being hidden behind buttons — it’s being organised properly from the start.

Building for What Comes Next

This change also removes a subtle scalability bottleneck. It becomes particularly useful as new workflow types are introduced — for example, ad-hoc expenses — where a flexible creation entry point avoids continually adding new “New …” buttons.

Instead of continuously adding more “New X Smart Schedule” buttons, new schedule types now plug into a consistent framework: a shared entry flow with a clear first decision point.

That should make future expansion — whether that’s new schedule types, scenario-based scheduling, or portfolio-level automation — much easier to integrate without UI rewrites.

Closing Thought

It’s interesting how something as small as a button can quietly shape the architecture of a feature over time.

What started as two simple actions evolved into a single entry point, and has now become a structured creation flow.

Nothing flashy on the surface — but a much more scalable foundation underneath.