DEV Community: GraceSoft

Day 9: File Uploads Are More Dangerous Than I Thought

GraceSoft — Sat, 25 Apr 2026 06:04:51 +0000

I already had an attachments system.

It worked across all modules.

Reusable. Clean. Flexible.

But I hadn’t thought deeply about one thing:

Privacy.

⚠️ The Risk

Files can contain:

Personal data
Sensitive documents
Things that should never be public

And if handled badly?

They become a liability.

🔐 What I Changed

I redesigned attachments with privacy in mind:

Private by Default

Files are private unless explicitly made public

Signed URLs

Temporary access links
Expire after a set time

Transparency

Each file shows:

Who uploaded it
Where it’s used

🧠 The Insight

Files are not just assets.

They are data.

And they need the same level of care.

🚀 Bigger Picture

Now my attachments system isn’t just reusable.

It’s:

Safe by design.

Which means every future module benefits automatically.

🧠 Final Thought

At this point, something clicked.

I’m no longer just building features.

I’m building:

defaults that shape behaviour

Day 8: I Built a Timeline to See the Life of Data

GraceSoft — Wed, 22 Apr 2026 04:49:08 +0000

Once I added context…

I still felt something was missing.

Data wasn’t static.

It changed over time.

So I asked:

What if I could see the history of a piece of data?

🧵 The Idea

A Data Timeline

📊 What It Shows

For each user:

When data was created
When it was updated
Whether it came from Stripe / Postmark
Who triggered it (admin/system)

🤯 Why This Is Powerful

Instead of guessing:

“What happened here?”

You can now see:

“Here’s exactly what happened.”

🔍 Debugging Becomes Easier

This also changed how I debug things.

Instead of:

digging through logs
checking multiple systems

I can just:

Look at the timeline.

🧠 Unexpected Benefit

This isn’t just a dev feature.

It’s also:

Audit-friendly
Compliance-friendly
Support-friendly

Day 7: Showing Data Without Context Is Dangerous

GraceSoft — Tue, 21 Apr 2026 07:34:59 +0000

After masking data, I ran into another problem.

Even when data is safe…

It can still be confusing.

Example:

You see a user email.

But you don’t know:

Where it came from
Why it exists
Whether it’s still needed

🤯 The Problem

Raw data ≠ meaningful data

💡 The Fix

I redesigned the user view to include:

👤 Data Transparency

Each user now shows:

What data is stored
Why it’s stored
Where it came from

(form, webhook, import, etc.)

🧠 Why This Matters

Because transparency builds trust.

Not just for users.

But for developers too.

You don’t want to guess:

“Why is this field here?”

You want to know instantly.

🚧 Implementation Notes

This reused a lot of what I already built:

Webhook metadata
Logs
System tracking

Which made me realise:

Good architecture makes good UI easier.

Day 6: The One Toggle That Changed My Entire System

GraceSoft — Mon, 20 Apr 2026 05:04:32 +0000

I wanted something simple.

Not a policy.

Not a config file.

Not a checklist.

Something visible.

Something immediate.

That’s how I landed on:

Privacy Mode

🎛️ What It Does

When Privacy Mode is ON:

Emails are masked → d***@gmail.com
Names are masked → D*** L***
Attachments are blurred or hidden

🔥 The Important Part

It’s not just a feature.

It’s ON by default in production.

⚠️ Why Default Matters

Because defaults define behaviour.

If Privacy Mode was OFF by default:

Devs forget to turn it on
Data gets exposed
Problems happen

So instead, I made the safe path:

The easiest path.

🧠 Design Insight

Good systems don’t rely on memory.

They rely on defaults.

🚧 Implementation Thought

This wasn’t hard technically.

But it required:

UI masking logic
Conditional rendering
Environment awareness

Simple idea.

Big impact.

Day 5: I Almost Over-Engineered Everything

GraceSoft — Fri, 17 Apr 2026 08:47:41 +0000

At this point, GraceSoft Core was starting to take shape.

Architecture. Patterns. Principles.

Everything felt… solid.

And then I caught myself.

I was about to over-engineer the whole thing.

⚖️ The Tension

There’s always this trade-off:

Build it right vs
Build it fast

And I’ve been on both extremes before:

🚀 Too Fast

Hack things together
Ship quickly
Pay the price later

🧱 Too Perfect

Design everything upfront
Endless planning
Nothing actually ships

🤯 The Realisation

GraceSoft Core was at risk of becoming:

A system that’s beautifully designed… but never used.

💡 What Changed

I asked myself a different question:

“What’s the smallest version of this that actually works?”

Not:

Perfect architecture
Full feature set
Every edge case covered

Just:

Something real I can use in my current app.

🔑 New Principle

Build just enough core to remove friction — not all friction.

🚧 What I’m Focusing On Now

Instead of everything, I’m narrowing down to:

Auth (done properly once)
Basic integrations (Stripe, email)
Clean project structure
Reusable UI foundations

Everything else?

Can come later.

🧠 Honest Truth

I still feel the urge to overbuild.

To make it “complete”.

But I’m learning this:

A system becomes real when it’s used — not when it’s finished.

Day 4: Why I’m Designing Security First (Not Features)

GraceSoft — Tue, 14 Apr 2026 01:57:25 +0000

Most projects start with features.

I’m starting with something else:

Security.

🚨 Why?

Because retrofitting security is painful.

And I’ve felt that pain already.

🔐 What “Security-First” Means Here

For GraceSoft Core, it means:

Clear separation of internal vs public data (ID vs UUID)
Controlled integrations (Stripe, webhooks)
Environment-aware configurations
Safe defaults everywhere

⚖️ Trade-Off

Security-first doesn’t mean:

Over-engineering
Slowing everything down

It means:

Making the safe way the default way

🧠 Design Principle

If a developer has to remember to be secure…

The system is already flawed.

🚧 Still in Progress

I’m still figuring things out:

Vector DB support
API structure boundaries
Module separation

But one thing is clear:

Security is not a feature. It’s the foundation.

Day 3: I’m Designing a System Without Writing Code (Yet)

GraceSoft — Mon, 13 Apr 2026 03:05:05 +0000

This might sound strange:

I’m building a system…

Without writing any code.

🧠 Why?

Because I’ve made this mistake before:

Jumping into coding too early
Locking in bad decisions
Refactoring everything later

So this time, I’m doing something different:

I’m designing the system first.

🧱 What I’m Defining

Right now, I’m working from a requirements doc that outlines:

Tech stack decisions
Architecture rules
Integration points
System boundaries

(Yes, I’m treating this like a real product 😅)

⚙️ Some Core Decisions

Here’s what’s already shaping up:

Tailwind + Vite as default stack
Tokenised fonts and brand system
Structured asset handling (logos, wordmarks, env toggles)
Stripe + webhook-first integrations
REST + optional GraphQL

Everything is being designed to be:

Reusable
Predictable
Secure

🔗 Bigger Vision

This isn’t just a boilerplate.

It’s meant to connect to a bigger system:

GraceSoft HQ

Where apps can plug into shared services like:

Auth
Analytics
Feedback
Product data

🧠 vs ✋

Here’s the reality:

My brain is designing systems
My hands are still fixing bugs in my current app

And somehow…

Both are moving forward at the same time.

Day 2: The Patterns I Couldn’t Ignore

GraceSoft — Fri, 10 Apr 2026 09:01:06 +0000

After my “breaking point”, I started looking more carefully at my projects.

Not as separate apps — but as systems.

🔍 What I Noticed

Across both projects, the same patterns kept showing up:

🔐 Authentication

Every app needed:

Login
User ownership checks
Protected routes

🔗 Integrations

Every app needed:

Stripe
Email/webhooks
External services

🧱 Data Design

I kept defaulting to:

Internal IDs for performance
UUIDs for public exposure

Without even thinking about it anymore.

🎨 UI Foundations

Every project needed:

Fonts
Colors
Layout structure
Reusable components

🤯 The Real Problem

It wasn’t just repetition.

It was:

Re-deciding the same things over and over again.

💡 Insight

Good defaults = less mental load.

And right now?

I had none.

🧠 A Better Approach

Instead of rebuilding everything:

What if I had:

Pre-decided architecture
Pre-configured integrations
Pre-built foundations

That’s when “GraceSoft Core” started to feel real.

Day 1: I Got Tired of Rebuilding the Same Thing

GraceSoft — Thu, 09 Apr 2026 13:21:37 +0000

I didn’t start out trying to build a framework.

I was just trying to fix my app.

While working on my second project, I kept running into the same issues:

Rewriting setup logic
Rebuilding authentication
Reconfiguring environments
Reconnecting integrations

Then I went back to my first project to fix bugs and improve it so I could actually use it.

And that’s when it hit me:

Why do these two projects feel almost identical under the hood?

Even though they serve different purposes, I was rebuilding:

Auth
Webhooks
Config systems
UI foundations
Database patterns

Again. And again.

💥 The Breaking Point

At some point, it stopped feeling like progress.

It felt like:

“Why am I solving the same problem twice?”

💡 The Shift

Instead of asking:

“What does this project need?”

I started asking:

“What do all my projects need?”

🚧 What Comes Next

That question led me to something bigger:

👉 A shared foundation
👉 A reusable system
👉 A core

I’m calling it:

GraceSoft Core

No code yet.
Just thinking.

But this might be the most important part.

Day 3 — Smoothing Auth, Shipping Email Verification, and Making the UI Feel Real

GraceSoft — Wed, 08 Apr 2026 10:44:28 +0000

After getting the core timeline and billing foundations in place, Day 3 was about tightening the experience — especially around authentication, UI consistency, and the little things that make the product feel alive instead of stitched together.

A lot of this day was less about “new features” and more about removing friction.

🔐 Fixing Auth Friction (The Invisible Work That Matters Most)

Auth is one of those areas where small issues feel huge to users.

Today’s focus:

Prevent users from getting stuck on submit buttons
Avoid registration hanging during email verification
Ensure protected routes behave properly

Key fixes:

Deferred sending verification emails to avoid blocking registration
Fixed edge cases where submit buttons could get stuck
Properly gated app shell routes behind login

👉 Result:
Auth now feels instant, not fragile.

✉️ Email Verification That Actually Feels Designed

Instead of treating email verification as an afterthought, I gave it proper UI attention.

Updates:

Introduced a Sky-600 branded email canvas
Designed a clean outer container for verification emails
Updated logo usage for consistency

This is one of those subtle trust builders:

If your emails look polished, your product feels more legitimate.

🎨 UI Standardisation (Design System in Motion)

Things started drifting visually, so I pulled everything back into alignment.

Improvements:

Standardised primary CTAs with Sky styling
Aligned sidebar layout and GitHub connect controls
Refined UI surfaces across the workspace

Also introduced:

A reusable Lucide icon system for notes-style UI

👉 Result:
The app now feels like a system, not a collection of pages.

⚡ Timeline & Interaction Upgrades

The timeline is the heart of GraceSoft Story, so I focused on making it faster and more interactive.

Enhancements:

Added lazy-loaded fragments
Introduced optimistic UI for label interactions
Implemented mobile-first filters with preserved query state

👉 Result:
Snappier interactions and better mobile usability.

🧱 Refactoring Toward Reusability

Some earlier pages were getting messy, so I started consolidating patterns.

Refactors:

Converted story pages into a reusable notes-style shell
Cleaned up UI state handling across views

👉 Result:
Easier to scale features without duplicating logic.

📊 Chapter & Dev Workflow Improvements

Not everything is user-facing — some of the biggest wins were internal.

Additions:

“Changes” section in the chapter inspector
Research doc for GitHub sync improvements
TODO maintenance tracker

👉 Result:
Better visibility into both product and dev workflow.

🧠 Takeaway

Day 3 wasn’t about flashy features.

It was about:

Removing friction
Making interactions feel reliable
Bringing consistency across the product

This is the kind of work users don’t notice explicitly —
but they feel it immediately.

🚀 What’s Next

With auth and UI stabilised, next steps are likely:

Deepening GitHub sync reliability
Expanding chapter intelligence
Continuing to refine the story experience

Day 2 — Wiring Billing Into the Story (and Bringing the UI Back)

GraceSoft — Tue, 07 Apr 2026 11:24:33 +0000

Today started deep in the backend… and ended with the UI finally catching up.

The Problem

GraceSoft Story started as a way to turn commits into timelines.

But timelines alone aren’t a product.

To make this real, I needed:

billing
plans
feature access control

Without turning the codebase into a mess of if (plan === 'pro').

Step 1 — Plans Shouldn’t Live in Code

First thing I removed:

refactor(plans): remove implicit plan seeding

Plans don’t belong in migrations or seeders.

They belong in Stripe.

So instead of defining plans internally, I made Stripe the source of truth.

Step 2 — Sync Stripe → App

feat(stripe): store product details when syncing catalog

Now products and pricing live locally after sync.

This unlocks:

fast queries
feature mapping
no runtime dependency on Stripe API

Step 3 — Subscription Modeling

feat(billing): integrate account-plan-subscription schemas

I avoided the typical shortcut (user.plan).

Instead:

accounts
plans
subscriptions

This keeps things flexible for:

teams
shared billing
multiple repos per account

Step 4 — The Stripe Mapping Problem

fix(stripe): persist subscriptions using metadata tier mapping

Stripe doesn’t know your app’s logic.

So I used metadata to map:

Stripe products → internal tiers

This avoids brittle assumptions like name matching.

Step 5 — Feature Gating as Data

feat(plans): add pricing-gated feature schema
feat(stripe): refresh plan gates from catalog tier updates

Instead of hardcoding:

if ($user->plan === 'pro')

I now have:

feature definitions
tied to plans
dynamically synced

So the system can answer:

“Does this account have access to this feature?”

Step 6 — Event-Driven Billing

feat(api): add stripe and postmark webhook endpoints

Billing state is now:

async
event-driven
consistent

No more relying on user-triggered updates.

Step 7 — Document Before It Gets Messy

docs(readme): replace template with project documentation

Captured:

architecture
billing flow
schema decisions

Step 8 — Design Direction First

Before jumping into UI, I set the tone:

chore(ui): add design inspiration

Leaning towards:

pre-glass macOS feel
structured, calm interfaces
narrative-first layout

Step 9 — UI Catches Up

feat(ui): implement app shell and redesign core story pages

Finally:

app shell in place
story pages redesigned
layout aligns with the “timeline as narrative” idea

What Changed Today

Billing is no longer an afterthought
Plans are externalized
Features are structured data
UI is catching up to the system

More importantly:

The system now understands who gets to see what part of the story.

Closing Thought

Today wasn’t about flashy features.

It was about removing shortcuts.

Because the moment you introduce billing,
you’re forced to answer:

What is valuable?
What is restricted?
What is part of the story?

Tomorrow:

enforce feature gates across UI + API
connect usage → pricing
refine the UX around locked features

If you're building something similar,
how are you structuring feature gating without polluting your domain logic?

Day 1: Building a Timeline System on Top of Real Work

GraceSoft — Mon, 06 Apr 2026 13:54:16 +0000

I recently started working on something new under GraceSoft — an experiment around structuring “stories” from actual development activity.

Not content.
Not posts.
Not documentation.

Something closer to a timeline engine.

🧩 The Idea (So Far)

Most of our work already exists in fragments:

git commits
project updates
notes
milestones
decisions

But they’re scattered across tools.

What if they could be structured into a single, evolving timeline?

Not manually written after the fact —

but progressively built as the work happens.

⚙️ What’s Been Built (Day 1–?)

Still early, but the current foundation includes:

timeline creation (MVP structure)
ownership + access control layer
integration entry points (starting with GitHub)
manual sync endpoint
early-stage pipeline for processing activity into events

No UI direction locked in yet —

focusing purely on data modeling + system design first.

🧱 Current Stack

Laravel (API + core logic)
MySQL (structured timeline data)
GitHub integration (initial source)
Queue-based processing (for sync pipeline)

Keeping it simple for now —

but designing in a way that won’t break when things scale.

🤔 Open Questions

Still figuring out:

How much should be automated vs curated?
What makes a “meaningful” event in a timeline?
How to avoid turning this into just another activity feed?
Where does structure end and storytelling begin?

👀 What’s Next

expanding the sync pipeline
mapping commits → structured timeline events
experimenting with milestone detection
exploring a minimal UI (thinking macOS-inspired)

No roadmap to share yet.

Just building, testing, and seeing where this goes.

If you’ve ever thought about:

turning work into something more structured
or making development progress more visible

I’d be curious to hear your thoughts.