GraceSoft Story, Day 1: Building a Timeline System on Top of Real Work
I recently started working on something new at GraceSoft: an experiment in structuring “stories” from real 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 those fragments are scattered across tools. What if they could be structured into a single, evolving timeline, built up as the work happens instead of written by hand after the fact?
What’s been built
It’s still early, but the current foundation includes:
- timeline creation (MVP structure)
- an ownership and access control layer
- entry points for integrations, starting with GitHub
- a manual sync endpoint
- an early pipeline that turns activity into events
No UI direction is locked in yet. For now the focus is purely on data modelling and system design.
Current stack
- Laravel (API + core logic)
- MySQL (structured timeline data)
- GitHub integration (the first source)
- Queue-based processing (for the sync pipeline)
I’m keeping it simple for now, but designing it so it won’t break as it scales.
Open questions
I’m still working out:
- How much should be automated vs curated?
- What makes an event in a timeline “meaningful”?
- How do I avoid turning this into just another activity feed?
- Where does structure end and storytelling begin?
What’s next
- Expanding the sync pipeline
- Mapping commits to structured timeline events
- Experimenting with detecting milestones
- Exploring a minimal UI (thinking macOS-inspired)
There’s no roadmap to share yet. I’m 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 love to hear your thoughts.
Part of the GraceSoft Story build-in-public series. Originally published on DEV.