DEV Community: GraceSoft

Snap a Dish, Get a Recipe: Building GraceSoft DishLens Solo

GraceSoft — Wed, 05 Aug 2026 06:15:56 +0000

This week the recording of GraceSoft CMS's "vibe coding" series is on pause. Something more exciting pulled my attention: my first venture into mobile apps, via React Native.

The pitch is simple. Snap a photo of a dish, and get back a recipe you could actually cook at home, plus its nutritional breakdown. Building it has been anything but simple — but that's the part worth writing about.

I'm building both the API and the mobile app myself. This is a new domain for me, still a one-woman show, and I leaned on Claude Code to move fast. But moving fast isn't the hard part of a project like this — knowing which edge cases matter, what to log, and how to structure a pipeline so it doesn't quietly drift is. That's domain knowledge and dev instinct, and no tool hands that to you.

The shape of the system

Right now everything lives in one monorepo (pnpm + Turborepo), with two apps and a handful of shared packages (shared-db for Prisma/Postgres, shared-config for env validation, shared-logger for structured logging).

DriveSync is the backend service that keeps a Pinecone vector database in sync with recipes stored as Google Docs in a Drive folder.

DishLens is the API that takes a single-dish photo and returns a "homable" recipe and its nutrition info. It's paired with a React Native (Expo) app that's the actual user-facing product.

DriveSync is done. DishLens is still in bug-fixing mode.

DriveSync: keeping a vector DB honest

The job sounds simple — watch a Drive folder, sync new or changed docs into Pinecone. The details are where it got interesting:

Change detection against Google Drive, so I'm not re-processing documents that haven't changed.
Extraction pipeline that pulls text out of Docs, Sheets, Slides, and PDFs — each with different structure and failure modes.
Token-budgeted chunking with overlap, so embeddings stay within model limits without cutting a recipe's context in half.
Batched embedding generation via OpenAI, with retries, because batch jobs against a third-party API will fail partway through eventually — plan for it up front.
Dedup and stale-vector deletion, so a recipe that's edited or removed from Drive doesn't leave orphaned, outdated vectors haunting search results.
Postgres-backed sync state, plus job locking, so overlapping sync runs don't stomp on each other.
Observability: sync logs, failure alerts, and status/audit endpoints — because a background sync job that fails silently is worse than one that doesn't exist.

DishLens: from photo to recipe

This is where most of the genuinely hard problems live, because the input is a photo taken by a real person on a real phone — not a clean API payload.

The image pipeline, before anything else happens:

File-type and size validation, and pixel-dimension limits, to reject junk before it costs an API call.
EXIF-safe re-encoding that strips GPS data and normalizes orientation — a privacy requirement as much as a correctness one.
Laplacian-variance blur detection to reject blurry photos before they hit the vision model. This one mattered more than I expected: a blurry photo doesn't just produce a bad recipe, it produces a confidently wrong one, and rejecting it early is both cheaper and a better user experience than letting the model guess.

Dish detection and generation:

Google Vision handles dish classification, with edge-case handling for things like multi-dish photos (a full table spread instead of one dish) and moderation to filter inappropriate content.
Recipe generation runs through Anthropic Claude.
Nutrition data comes from Edamam, matched back to the generated recipe — so the numbers aren't just a model's guess, they're grounded in a real nutrition database.
Photos themselves are normalized, uploaded, and served from GCS with signed URLs.

Everything else an API needs to not fall over:

JWT-based auth shared across services, with per-user rate limiting on the upload endpoint.
A Redis-backed session store, scoped per user with TTLs.
Chat that can draw on a user's own synced recipes, not just what Claude generates fresh — and chat sessions that work even when no dish has been scanned, for general recipe/nutrition Q&A.
The usual account plumbing: password change, account deletion, GET /auth/me.

The React Native app

Built in Expo, developed in structured milestones (M1 through M7, across five "rounds") — brand foundations and auth screens first, then the scan flow, then chat and meal planning, then a full dark mode pass with semantic theme tokens and accessibility work.

A few things that ate more time than expected:

"Unsupported FormDataPart implementation" — a fun way to discover that multipart uploads behave differently across platforms and Expo versions.
Compressing and resizing photos client-side before upload, both for speed and to keep the backend's size limits happy.
Proactively refreshing access tokens instead of waiting for a request to fail and refreshing reactively — small change, noticeably better UX.
Wiring auth state through SecureStore so sessions survive app restarts without storing tokens somewhere they shouldn't be.

The unglamorous part: deployment

If the commit history is honest about anything, it's that deployment ate real hours: Railway build errors, Prisma's engine binaries needing OpenSSL inside Docker, and Turbo v2's strict envMode silently stripping environment variables it didn't recognize. None of this is interesting to write about, and all of it is the kind of thing that quietly determines whether a project ships.

Where Claude Code actually helped

Claude Code was genuinely useful for moving quickly through boilerplate and unfamiliar territory — this is my first time in React Native and Expo. But the bottleneck on a project like this was never typing speed. It was deciding that a blurry photo needs its own rejection path before the vision model ever sees it, that stale vectors need active deletion instead of just letting Pinecone grow, that a background sync job needs an audit endpoint because "it probably worked" isn't good enough. Those are judgment calls that come from domain knowledge and experience, not from a tool.

What's next

DriveSync and DishLens currently share a monorepo. That's changing:

GraceSoft DriveSync and GraceSoft DishLens API are moving into separate repos.
DriveSync is headed toward open source, once I clean it up a bit more.
DishLens API stays proprietary — it'll power the GraceSoft DishLens app going forward.

DishLens (the API) is still in bug-fixing mode, and the app is catching up to it feature by feature. More to come as both stabilize.

Still a one-woman show at GraceSoft. If you've built something similar — recipe generation, vector sync pipelines, or your first React Native app — I'd love to hear how you tackled it.

Why GraceSoft Dropped GitHub Copilot for Claude Code

GraceSoft — Mon, 03 Aug 2026 17:54:12 +0000

GitHub Copilot was my default AI coding assistant for a long time. It handled inline completions well and slotted cleanly into my editor workflow.

In May, I started running Claude Code alongside it — not as a replacement yet, just a parallel track. For the past few months, I've used both at GraceSoft, task by task, watching where each one actually wins.

What tipped it

Copilot is strong at fast, local completions — finishing the line or function you're already writing. Where it fell short for me was anything that spanned more than one file: understanding how a change in a service layer should ripple into its tests, its callers, and its docs. That's where Claude Code pulled ahead. It reasons across the codebase rather than just the cursor position, and it can carry out multi-step tasks — refactors, migrations, debugging loops — without me having to babysit every intermediate step.

The decision

Three months of A/B testing on real GraceSoft codebases gave me enough signal: I'm dropping Copilot and moving fully to Claude Code. The difference showed up most in multi-file context handling and agentic task completion — not just autocomplete quality.

If you're on the fence, don't take my word for it — run your own side-by-side for a sprint or two. Happy to share more specifics on my eval process if there's interest in the comments.

Migrating from Astro to Laravel + Postgres + Cloudinary — and why my first plan didn't survive contact with reality

GraceSoft — Tue, 07 Jul 2026 10:24:14 +0000

Quick devlog on a content migration I'm running for my personal site (davdevs-laravel): moving from a flat-file Astro content repo into a Laravel app backed by PostgreSQL, with Cloudinary handling media.

The wasted day (sort of)

I spent a full day writing .md guideline documents — step-by-step instructions for Claude Code to handle the migration autonomously.

The next day, reviewing it with fresh eyes, I realized the whole plan was built around the wrong topology: I'd designed it as a local-to-local transfer, since both the old and new repos live on my dev machine right now. But the actual migration target is local-to-cloud (Cloudinary for media, hosted Postgres for data), and that changes sequencing, validation, and rollback enough that the original docs weren't salvageable as-is. Today's commits tell that story pretty directly:

Updated migration docs
Updated migration plan to audit images
feat: content migration audit + import commands (Phase 22, step 1)

I'm also still somewhat skeptical of how cleanly Claude Code will execute a migration like this end-to-end — subtle content breakage is easy to miss — so I made the image importer resumable and resilient to per-file failures (Make migration:import-images resumable and resilient to per-file failures) rather than treating it as one big atomic job. If it dies on file 340 of 500, I don't want to start over.

Two content types that needed real design decisions

1. Tool pages with attached React components

Each /tools post has a React component embedded alongside it. The instruction to Claude Code was scoped narrowly:

Migrate only the components inside /tools
Update the color scheme to match the new site — e.g., yellow buttons replacing blue

Shipped as Add React Component Manager for Tools.

2. Ebook product pages (uniquely designed, per ebook)

This was the harder one. Every ebook product page was hand-designed as a one-off — great for bespoke launches, terrible for migrating raw code into storable DB records.

The solution: stop treating each page as unique. Consolidate all ebook product pages into two layout variants — individual and bundle — and adapt the publications module to support full design customization within those two variants. This landed as Publication Template Manager for eBooks, in the same commit as the tools work — 87346c7: Add React Component Manager for Tools + Publication Template Manager for eBooks.

Worth noting this builds on a longer architecture already in place from prior phases — publication manager, taxonomy CRUD, headless REST API, JSON-LD/OG tags — so the template consolidation slots into an existing content model rather than a bolt-on.

Starting Development on GraceSoft RSVP — A Real-Time Wedding Operations Dashboard Powered by Google Sheets

GraceSoft — Fri, 15 May 2026 06:23:40 +0000

We’ve officially started development on GraceSoft RSVP — a mobile-first, real-time wedding operations dashboard built around Google Sheets synchronization.

The initial idea came from a simple real-world question:

“Is it possible to build a live dashboard connected to a Google Spreadsheet that updates automatically as the spreadsheet changes?”

The answer was yes — but rather than building a simple spreadsheet viewer, we decided to approach the problem like an operational platform.

The Vision

GraceSoft RSVP is designed to help:

couples
coordinators
wedding helpers

…manage guest operations in real time.

The goal is to transform familiar spreadsheet workflows into a responsive, mobile-friendly operational dashboard experience.

Instead of requiring users to learn a custom admin panel, the spreadsheet itself becomes the content management system.

Users continue updating guest information in Google Sheets while the dashboard automatically reflects changes live.

Why Google Sheets?

One of the most interesting engineering aspects of this project is that the source dataset is intentionally flexible.

We may not always control:

column naming
column order
optional fields
spreadsheet formatting

This means the application cannot rely on hardcoded indexes or rigid schemas.

The dashboard has to adapt dynamically.

That led us toward building:

dynamic header mapping
normalization layers
typed transformation pipelines
resilient data parsing systems

rather than directly binding UI components to spreadsheet cells.

Core Architecture

The current planned architecture looks something like this:

Google Sheets
      ↓
Google Sheets API
      ↓
Normalization Layer
      ↓
Typed Guest Models
      ↓
Dashboard API
      ↓
Reactive Mobile UI

Rather than exposing the spreadsheet directly to the frontend, the server transforms raw spreadsheet data into structured internal models.

This gives us:

schema flexibility
safer parsing
cleaner frontend architecture
reusable analytics systems
future scalability

Technical Goals

This project is also an opportunity to explore several frontend engineering concepts in a practical production-like environment.

Planned Technical Features

Dynamic Header Mapping

The dashboard should continue working even if spreadsheet columns change names or move positions.

Examples:

RSVP
RSVP Status
rsvp_status
Guest RSVP

All of these should map correctly.

This introduces:

normalization utilities
synonym matching
defensive parsing strategies

Real-Time Updates

The dashboard should update automatically without refreshing the page.

The initial implementation will likely use polling with SWR refresh intervals.

Later phases may introduce:

Server-Sent Events (SSE)
streaming updates
activity feeds
reactive state synchronization

Typed Data Models

All spreadsheet data will eventually be transformed into typed models.

Example:

type Guest = {
  id: string;
  name: string;
  side?: string;
  pax?: number;
  rsvpStatus?: string;
  arrivalStatus?: string;
  diet?: string;
  table?: string;
};

This creates a clean separation between:

external datasets
application logic
presentation layers

Mobile-First Operations UI

Wedding coordinators and helpers are likely to use the dashboard primarily on phones during live events.

The UI is therefore being designed mobile-first with:

touch-friendly cards
responsive layouts
searchable guest lists
real-time status indicators
operational analytics

Planned Dashboard Views

Operations Dashboard

A high-level overview screen showing:

total guests
confirmed RSVPs
arrivals
dietary analytics
live activity updates

Arrival View

A view-only operational guest list showing:

guests who have arrived
side allocation
dietary restrictions
table information

This screen is intended for:

coordinators
helpers
ushers
logistics support

Nice-to-Have Features

Some planned experimental features include:

QR-based guest check-in
passcode-protected dashboards
activity logs
live synchronization streams
operational analytics

Current Tech Stack

Current planned stack:

Next.js 15
TypeScript
Tailwind CSS
shadcn/ui
Recharts
Google Sheets API
SWR
Zod

Hosting will likely be handled through Vercel.

Security & API Design

One important engineering decision is that the raw spreadsheet will never be exposed publicly.

The application uses:

server-side Google Sheets fetching
readonly service account permissions
internal normalization pipelines
environment-based credential management

The spreadsheet behaves like a backend CMS, while the frontend remains a structured operational interface.

Why This Project Is Interesting

What started as a wedding helper tool quickly evolved into something broader:

a lightweight real-time event operations platform.

The underlying architecture could eventually support:

conferences
ministry events
church attendance systems
volunteer operations
registration workflows
hospitality coordination

Next Steps

Current milestones include:

setting up Google Sheets synchronization
building normalization utilities
implementing typed guest models
creating responsive dashboard layouts
implementing real-time polling updates
designing reusable analytics components

We’ll continue documenting the development process publicly as the project evolves.

More updates soon 👀

I Built a WhatsApp Booking Agent — The Hard Part Wasn’t AI

GraceSoft — Sat, 02 May 2026 09:45:05 +0000

Building GraceSoft Sentinel Concierge: From WhatsApp Bot to Production Booking Agent

I spent the last stretch building GraceSoft Sentinel Concierge — a WhatsApp-first concierge agent designed to handle customer enquiries, FAQs, bookings, and business handover without requiring users to download another app.

What started as “a simple WhatsApp assistant” quickly turned into a full production exercise in systems design, operational resilience, and the kind of edge-case engineering that only shows up when real users start sending messy messages.

This is the dev log of what I built, what broke, and what I learned.

What GraceSoft Sentinel Concierge Is

GraceSoft Sentinel Concierge is a WhatsApp concierge agent for service businesses.

Its job is simple:

answer FAQs
detect booking intent
suggest available slots
create bookings
escalate to a human when confidence drops
avoid sounding robotic while doing all of the above

Under the hood, it’s doing much more than that.

This became less of a chatbot project and more of a stateful booking orchestration system with WhatsApp as the UI.

Stack

I kept the stack intentionally lean:

Node.js + Express — webhook and API layer
TypeScript — typed flows and safer service boundaries
Prisma — schema and database access
MySQL — persistent booking and business data
Redis — ephemeral booking state, session memory, dedupe, rate limiting
Google Calendar API — slot availability + booking sync
Docker — local + deployment consistency
Railway — deployment and runtime hosting

This stack gave me the flexibility to move fast without overengineering too early.

What I Built

Over a few intense iterations, Sentinel Concierge grew from a webhook listener into a proper booking system.

Phase 1: Foundation

WhatsApp webhook handling
environment validation
Prisma + MySQL setup
Redis-backed session state
basic FAQ routing
structured logging with PII redaction

Phase 2: Intent + Handover

FAQ intent matching
booking intent detection
fallback confidence handling
business handover escalation
manual help command routing

Phase 3: Booking Engine

date/time extraction from natural messages
booking slot generation
preferred-time ordering
invalid date rejection
timezone-safe slot formatting
Google Calendar booking sync

Phase 4: Ops Hardening

webhook dedupe
Redis reconnect resilience
startup health probes
deployment readiness checks
traceable logs
prompt injection safety
rate limiting

Phase 5: Business Logic Hardening

public holiday awareness
“day in lieu” logic
weekday/flexi-hours mapping
legal pages
booking cancellation TODOs
human-readable booking references

At this point, it stopped being “just a bot.”

It became a production system.

The Hard Parts (and What Broke)

This was the real work.

The code was rarely the hardest part.

The hard part was making the system behave correctly under real-world ambiguity. That’s where most of the engineering time went — which is also where most “AI agent” demos quietly fall apart. (DEV Community)

1. WhatsApp Is Not a Clean Interface

Users do not send clean structured input.

They send:

“tmr 3ish can?”
“this sat after lunch”
“book for next week maybe”
“actually nvm can cancel”

Natural language booking sounds easy until you have to convert vague intent into deterministic business actions.

The challenge wasn’t understanding language.

The challenge was deciding when not to act.

That meant building:

ambiguity thresholds
safe fallbacks
clarification loops
escalation rules

The hardest part of conversational systems is rarely parsing text.

It’s preventing bad automation.

2. Booking Logic Is Mostly Edge Cases

Booking systems sound simple until you hit reality:

timezone drift
invalid dates
public holidays
day-in-lieu holidays
flexi business hours
conflicting calendar events
duplicate booking attempts
partial confirmations

Most of the complexity in Sentinel Concierge came from one thing:

making sure the system never confidently books the wrong thing.

This meant spending more time on:

slot filtering
booking validation
idempotency
human-readable confirmation states

…than on the chatbot itself.

3. Webhooks Are Messy in Production

Webhook systems are noisy.

Retries happen.
Duplicate events happen.
Out-of-order events happen.

A clean local demo does not prepare you for production webhook behaviour.

I had to add:

dedupe protection
replay-safe handling
startup resilience
Redis reconnect recovery
safer initialization for Prisma

This was one of the biggest shifts in the project:

moving from “it works locally” to “it survives production.”

4. The Real Product Was State

The biggest architectural shift was realising the product was not the WhatsApp layer.

The product was state management.

WhatsApp is just the interface.

The real system is:

what the user already said
what step they’re in
whether they’re asking or confirming
whether the system is waiting for clarification
whether escalation already happened
whether the booking should still be considered active

That changed how I designed everything.

Redis stopped being “nice to have” caching.

It became the operational backbone of the conversation flow.

5. “AI” Was the Least Interesting Part

The most useful lesson from building this:

the intelligence was not in the model.

It was in:

routing
safeguards
confidence thresholds
fallback rules
operational boundaries
deterministic business logic

The LLM helped with interpretation.

The system did the real work.

That distinction matters.

A lot of “AI product” demos are really just prompt wrappers.

This project became useful only when the operational logic became stronger than the prompt.

What I Learned

A few things became very clear while building this.

1. The happy path is a lie

The happy path is the demo.

The product is everything outside it.

2. Operational resilience matters more than clever prompts

Prompt quality matters.

But retries, dedupe, health checks, and state recovery matter more.

3. Most AI systems fail at boundaries

Not generation.

Boundaries.

When to ask.
When to wait.
When to escalate.
When to stop.

That’s the real product.

4. Booking systems are trust systems

Users forgive slow replies.

They do not forgive wrong bookings.

Reliability matters more than speed.

What’s Next

Next up for Sentinel Concierge:

booking cancellation flow
rescheduling flow
admin controls
booking audit history
business-facing dashboard
analytics on drop-off / escalation / booking completion
multi-business tenancy

The WhatsApp layer works.

Now the real product work begins.

Final Thought

GraceSoft Sentinel Concierge started as a WhatsApp AI assistant.

It turned into a lesson in production systems, conversational state, and the uncomfortable truth that most of the work in “AI products” has very little to do with AI.

And honestly?

That was the most useful part of building it.

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.