This is a submission for the GitHub Finish-Up-A-Thon Challenge.

I Revived SketchFlow: Turning an Abandoned Canvas App Into a GitHub-Native Visual Workspace

There is a strange feeling that comes from opening an old repository.

Not because the code is bad.

Because you can still see the version of yourself who believed in the idea.

That is what happened when I reopened SketchFlow.

It started as a simple idea: what if builders could think visually, write project notes, organize diagrams, and keep everything connected inside one workspace?

At first, I imagined it like a mix of Excalidraw, Eraser, and a developer notebook. A place where a founder, designer, student, or engineer could sketch a system, write the surrounding context, export assets, and come back later without losing the story behind the project.

The early version had ambition.

It had a canvas.

It had documents.

It had authentication.

It had project structure.

But it did not feel finished.

It felt like one of those repositories that had a big vision, many moving parts, and not enough polish to confidently show to people.

So it slowly became another unfinished project sitting on GitHub.

Then the GitHub Finish-Up-A-Thon gave me the exact push I needed.

Instead of starting yet another new idea, I decided to come back to SketchFlow and finally turn it into something sharper, clearer, and closer to the product I originally imagined.

What I Built

SketchFlow is a GitHub-native visual workspace for builders.

The goal is simple:

Excalidraw-like creation, Eraser-like project flow, GitHub-native ownership, and AI-ready project memory.

Most visual tools store your work inside their own closed system. SketchFlow takes a different direction. The core idea is that your sketches, docs, exports, assets, metadata, and history should live in a GitHub repository that you own.

That means the project is not only a drawing tool.

It is a workspace where visual thinking becomes part of your actual developer workflow.

In the revived version, SketchFlow focuses on this loop:

1. Create or connect a GitHub-backed workspace.
2. Start a project.
3. Sketch ideas visually with an Excalidraw-powered editor.
4. Write notes and project context beside the canvas.
5. Save a snapshot into GitHub.
6. Keep history, assets, metadata, and future public pages connected to the repo.

The bigger vision is to make SketchFlow a place where builders can plan products, map systems, explain architecture, organize ideas, and preserve the context behind their work without locking everything inside a private database.

Demo

Live Demo: [ADD_LIVE_DEMO_LINK_HERE]
GitHub Repository: https://github.com/SH20RAJ/sketch-flow
Original/Older SketchFlow Repository: https://github.com/unstory-app/sketchflow

Screenshots

Add 4–6 screenshots here. Use captions so judges immediately understand the before/after.

Before: the older unfinished SketchFlow direction

After: the revived GitHub-native workspace

GitHub-connected workspace onboarding

Visual canvas editor with local draft saving

Manual GitHub snapshot save

Project dashboard with sync state

The Comeback Story

The first version of SketchFlow tried to do a lot.

It was a collaborative workspace for designers and developers. It combined a visual canvas, rich-text documents, project management, authentication, auto-save, exports, dark mode, and more.

That sounded powerful, but it also made the project heavy.

The problem was not that the idea was weak.

The problem was that the product identity was not sharp enough.

Was it a canvas app?

Was it a document editor?

Was it a project manager?

Was it a collaboration tool?

Was it a diagramming product?

The answer was: yes, kind of — and that was exactly the issue.

When I reopened the project, I realized I did not need to add every feature in the world. I needed to finish the core loop.

So I reframed SketchFlow around one strong direction:

A visual workspace where the user owns the data in GitHub.

That changed everything.

Instead of treating the database as the main source of truth, I redesigned the architecture so GitHub becomes the durable storage layer for sketches, docs, exports, assets, metadata, and history.

The app database stays intentionally small. It stores operational metadata like user identity, GitHub connection, workspace pointers, sync events, and future billing state.

The actual project content belongs to the user.

That became the heart of the revival.

Before

The older version had many good parts, but it still felt unfinished:

• The product direction was broad and slightly scattered.
• The app wanted to be a canvas, document editor, collaboration tool, and project manager at the same time.
• Storage was more traditional and app-centered.
• The GitHub ownership story was not the central idea.
• There were many features, but the main user loop was not clear enough.
• It felt more like a promising technical prototype than a focused product.

The project had the bones of something useful, but it needed a sharper reason to exist.

After

The revived SketchFlow has a much clearer identity:

• GitHub-native workspace model.
• Excalidraw-powered visual editor.
• Local IndexedDB draft saving for fast editing.
• GitHub repo bootstrap flow.
• Multi-file snapshot commits for scenes, project metadata, and notes.
• Dashboard with workspace cards and sync status.
• A repository structure designed for long-term ownership.
• A roadmap for public project pages, visual history, exports, docs, collaboration, and AI memory.

The biggest change is not just visual polish.

The biggest change is product clarity.

SketchFlow now has a clean answer to the question:

Why should this exist?

Because builders think visually, but their real work already lives in GitHub. SketchFlow connects those two worlds.

What Changed Technically

The revival focused on making the architecture more intentional.

1. GitHub as the durable source of truth

SketchFlow is designed so the user’s repository stores the durable project data.

A bootstrapped workspace repo can contain:

.sketchflow/
  manifest.json
  workspace.json
  latest.json
  indexes/
    public-projects.json
    search-index.json
projects/
  {projectSlug}/
    project.json
    sketches/
      {sketchSlug}.excalidraw.json
    docs/
      notes.md
    exports/
    assets/

This structure makes the project portable, inspectable, and more aligned with developer workflows.

2. Snapshot-based saving instead of noisy commits

A drawing tool should not commit every canvas stroke.

That would create unnecessary Git noise.

So SketchFlow uses local drafts for instant editing and manual GitHub snapshot saves for meaningful versions.

That makes the workflow feel fast while still preserving history.

3. Smaller app database

Instead of storing every sketch scene in Postgres, the app database stores only the operational metadata:

• user identity
• GitHub connection
• workspace pointer
• sync events
• future billing metadata

The actual project data remains in GitHub.

4. Clearer MVP user journey

The revived flow now focuses on a simple path:

1. User lands on SketchFlow.
2. User signs in.
3. User connects GitHub.
4. SketchFlow creates or connects a workspace repository.
5. User opens the dashboard.
6. User creates a project.
7. User sketches ideas visually.
8. User saves a snapshot to GitHub.
9. User can later load, export, publish, or version the project.

This is the kind of loop that makes the app feel real instead of just experimental.

My Experience with GitHub Copilot

GitHub Copilot helped most during the parts where I needed to move from idea to implementation without getting stuck in repetitive setup work.

It was especially useful for:

• breaking the revival into smaller implementation steps
• refactoring confusing parts of the older project direction
• planning a GitHub-backed data model
• generating API route scaffolding
• improving TypeScript types around workspace metadata
• thinking through the difference between local drafts and durable snapshots
• writing safer helper logic for GitHub sync flows
• improving naming, copy, and product messaging
• turning vague roadmap notes into concrete tasks

The biggest benefit was not that Copilot “built the app for me.”

The biggest benefit was momentum.

When you reopen an old project, the hardest part is often re-entering the codebase. You see unfinished files, old decisions, half-built flows, and a long list of things that need cleanup.

Copilot reduced that friction.

It helped me ask better questions:

• What is the smallest complete user loop?
• What should be stored locally?
• What should be stored in GitHub?
• What should never be committed?
• How do I keep the database small?
• How do I design the repo structure so users can understand it later?

That changed the process from “fix everything” to “finish the core loop.”

What I Pushed Back On

Copilot is fast, but finishing a project still requires taste and judgment.

There were several areas where I had to slow down and make decisions myself.

For example, it is tempting to make every canvas change sync instantly to GitHub. That sounds impressive, but it would create a terrible Git history and could hit API/rate limits quickly.

So I kept live editing local and made GitHub saves intentional.

It is also tempting to store everything in the database because that is easier to query. But that would weaken the main product idea: user-owned project memory in GitHub.

So I kept the database small and treated GitHub as the durable storage layer.

That is what I learned most during the revival:

AI can accelerate implementation, but product direction still has to come from the builder.

What I Learned

Reviving SketchFlow taught me that unfinished projects are not always failed projects.

Sometimes they are projects that had too many possible futures.

The work of finishing is choosing one.

For SketchFlow, the chosen future became clear:

A GitHub-native visual workspace for builders who want to own their ideas, diagrams, docs, and project memory.

This challenge also reminded me that a polished product is not only about adding features.

It is about making the product understandable.

Before, SketchFlow was powerful but blurry.

Now, it has a clearer loop:

• think visually
• write context
• save to GitHub
• preserve history
• build on top of your own repo

That is the comeback.

What Comes Next

SketchFlow is still early, but the revived direction gives it a much stronger foundation.

Next, I want to work on:

• public read-only project pages
• version timeline and visual history
• SVG, PNG, Markdown, and docs export pipeline
• docs beside sketches
• live collaboration with Yjs and Redis
• AI BYOK support
• AI project memory based on the GitHub-backed workspace
• better publishing and sharing workflows

The long-term idea is that every project can have a visual memory layer.

Not just code.

Not just docs.

But sketches, decisions, diagrams, notes, exports, and context — all connected to the repo.

Final Thoughts

SketchFlow started as an unfinished canvas app.

Then it became an unfinished collaborative workspace.

Now it is becoming something much clearer:

a GitHub-native visual workspace where builders own the full context of their projects.

That is what made this project worth reviving.

Not because it was the easiest repo to finish.

But because the idea still felt alive.

The Finish-Up-A-Thon pushed me to stop treating SketchFlow as “something I’ll finish later” and finally turn it into a product direction I can keep building on.

And honestly, that feels more meaningful than starting something new.

---

Links

• Live Demo: [ADD_LIVE_DEMO_LINK_HERE]
• GitHub Repository: https://github.com/SH20RAJ/sketch-flow
• Older SketchFlow Repository: https://github.com/unstory-app/sketchflow
• My GitHub: https://github.com/SH20RAJ
• My Portfolio: https://sh20raj.github.io/

---

Cover Image / Poster Prompt

Use this prompt in Genspark Designer, ChatGPT image generation, Canva AI, or any poster tool:

Create a premium DEV.to article cover image for a project called “SketchFlow”. Theme: GitHub-native visual workspace for builders. Show a dark modern workspace UI with an infinite canvas, hand-drawn system diagram nodes, GitHub repository/file tree on the side, commit history/timeline, and a subtle Excalidraw-style sketch aesthetic. Add large title text: “I Revived SketchFlow”. Subtitle: “From abandoned canvas app to GitHub-native visual workspace”. Style: clean SaaS launch poster, developer-focused, black/charcoal background, neon blue/purple accents, glassmorphism cards, minimal but high-impact, 16:9 DEV cover image, no clutter, sharp typography, premium open-source product feel.

Poster Text Layout

Top-left small label:
GitHub Finish-Up-A-Thon Submission

Main headline:
I Revived SketchFlow

Subtitle:
From abandoned canvas app to GitHub-native visual workspace

Three small chips:
Canvas • GitHub Sync • Project Memory

Footer:
Built by Shaswat Raj

First Comment to Add After Publishing

Thanks for reading! I’m still shaping SketchFlow, so feedback on the GitHub-native workflow would mean a lot. The main question I’m exploring is: should visual project memory live inside the user’s repo instead of being locked inside another SaaS database?

X / LinkedIn Share Text

I revived SketchFlow for the GitHub Finish-Up-A-Thon.

It started as an unfinished canvas app.
Now it’s becoming a GitHub-native visual workspace where sketches, docs, exports, metadata, and history live in a repo the user owns.

DEV post: [ADD_DEV_LINK]
Repo: https://github.com/SH20RAJ/sketch-flow