December 2025: From ideas to action

December was about building the foundations for turning ideas into action — and tightening the systems that make everything more reliable.

With collaboration and core workflows in place, we focused on three things:

• Making tasks first-class citizens in Walling
• Clarifying one of the most important (and complex) flows in the app: user registration
• Applying cleaner architectural boundaries to critical wall-based experiences

Here’s what we shipped:

1. Task management foundations

Tasks are a natural extension of how people already work in Walling. Notes turn into to-dos, plans gain deadlines, and collaboration requires clear ownership.

This month, we laid the groundwork for task management as a core system.

a. Task assignments: accountability, timing, and reminders

At the center of task management is the concept of a task assignment.

Task assignments hold:

• Assignees — who is responsible
• Due dates — shared deadlines that keep everyone aligned
• Reminders — personal nudges that trigger notifications

Due dates are global and consistent for everyone involved, while reminders are user-specific — allowing each person to manage how and when they’re reminded without changing the shared deadline.

This separation keeps tasks collaborative while still respecting individual workflows.

Also, now when you add a due date and there is no one assigned to a task item, the system auto-assigns the task to you and it appears in your My Assignments page for easy tracking. This was a user requested feature that we have folded in to this implementation.

b. Tasks live where work already happens

Task assignments aren’t limited to a single surface. You can add them:

• To bricks, turning any chunk of content into an actionable item
• To task items inside the editor for more granular, inline work

This flexibility lets tasks emerge naturally from your ideas — instead of forcing you into a separate task tool. Create tasks within your project context, content and flow. Then view your tasks clearly organized in one place (see My Assignments below).

c. Task items as first-class editor nodes

Task items are now a native part of the editor, which means they behave consistently everywhere you work.

You can:

• Create tasks inline with your content
• Convert a checklist item into a task item (and vice versa)
• Assign owners, due dates, and reminders without leaving context

Because task items are real editor nodes, they integrate cleanly with your other content ensuring all context is preserved.

d. My Assignments: a single view of what’s on your plate

As tasks become more embedded across Walling, it’s critical to have a single, clear place to review your responsibilities.

The My Assignments page brings together:

• All tasks assigned to you (bricks + task items)
• Across all walls within the active workspace
• In one centralized, actionable view

This ensures nothing slips through the cracks as tasks are created throughout the app.

2. A clearer, more deterministic user registration flow

User registration might look simple from the outside (and *should* feel simple to you), but it’s one of the most critical and interconnected flows in the product.

To set users up for success, registration needs to orchestrate multiple systems — reliably and in the right order.

This month, we refactored the entire flow to make it explicit, deterministic, and easier to reason about.

What registration now guarantees

On sign-up, we now clearly sequence:

1. Create the user in our system
2. Trigger required setup:

• Accept pending invites (if any)
• Create a workspace
• Start a trial subscription
• Create a welcome wall
• Mark the user active

3. Trigger notifications, onboarding, and analytics

By making this flow explicit, we reduced ambiguity, edge cases, and hidden coupling between systems.

Why this matters

Beyond improving reliability, this refactor surfaced opportunities to:

• Reduce bug-prone surface area
• Improve observability and debugging
• Prepare the system for future onboarding and growth features

It’s a quieter change — but one that significantly strengthens the foundation of the app.

3. Refactoring core wall workflows with clearer boundaries

With a sharper understanding of our architectural layers and responsibilities, we revisited several critical wall-based user flows.

This work is intentionally methodical:

• Design the refactor before touching code
• Execute changes in the right order based on dependencies
• Add validation and testing along the way
• Deprecate legacy paths instead of patching around them

While it takes more time upfront, the payoff is already visible.

What we’re seeing

• Cleaner, more predictable behavior
• Faster interactions as complexity is reduced
• Code that’s easier to extend without fear of regressions

These improvements compound — making every future feature easier to build and more reliable to ship.

Looking ahead to January 2026

December’s work sets us up for a strong start to the new year.

Next, we’ll continue to:

• Enhance task workflows and surfacing, and improving the UI/UX: editor UX, assignees selection menu, reminders setting menu, My Assignments page data flow and UX
• Refactor additional core workflows to adhere to clearer architectural boundaries and reduce surface area for bugs and edge cases improving reliability and performance across core flows
• Establishing criteria and a roadmap for beta release that will allow us to get the new version of Walling to beta testers while we continue to refine and improve

Challenges we’re facing

Transitioning toward beta readiness

Over the first six months of our re-development process, we created a completely new architecture for Walling — defining the technologies, structure, core patterns, and initial systems that everything else builds on (see our October post for details).

As we continue layering real features on top of that foundation, we’re naturally uncovering optimization opportunities: clearer boundaries and separations, better patterns, stronger abstractions, and simpler flows. This kind of refinement is an expected (and important) phase once a software system starts being exercised in real ways.

For example, early on we optimized for speed by organizing much of the web code in a component-based structure. As the product has grown, we’re now refactoring toward a feature-based organization, with related components, hooks, and services co-located. This makes features easier to reason about, reduces cross-cutting complexity, and allows us to adhere more strongly to our architectural principles over time.

We’re also investing in a shared API and SDK layer. While our focus today is the web app, this allows us to centralize reusable logic so future clients — mobile, tablet, browser extensions, and AI-powered experiences — can build on the same foundation. Doing this work now avoids duplicated effort later and meaningfully accelerates our ability to expand Walling beyond the browser when the time is right.

While this work never truly ends, we believe there is a level of architectural stability that will meaningfully accelerate momentum instead of slowing us down when we release our beta. We’re focused on reaching that point, so that once feedback starts flowing, we can respond quickly and confidently — without grinding development to a halt or getting stuck in costly debug loops.

Our goal is to release a product that’s not only usable, but resilient — one that’s ready to absorb feedback and evolve rapidly through beta and into production.

Happy new year and we’re excited to release the new version of Walling in 2026!

Thanks for following along!

If there is anything that you’d like to hear about in more detail as we continue to progress, please feel free to drop us a note!

— The Walling Team