Inspiration
We were tired of watching people struggle with workflow automation tools that feel like they were designed for engineers, not creators. Every existing solution either overwhelms you with complexity or oversimplifies to the point of being useless. Tools like Zapier and n8n are powerful but intimidating. Retool is flexible but assumes you already think like a developer. We wanted something that feels like Canva, but for building workflows. Something where you open it up, see a clean dashboard, pick a template or start from scratch, and just build. The name "Dorian" came from the idea of something elegant on the surface with serious power underneath. We believe workflow tooling should meet people where they are, not where engineers wish they were.
What it does
Dorian is a workflow builder with a polished, Canva-inspired dashboard experience. Users sign up with an email and password, complete a 7-step onboarding flow, and land on a personalized dashboard that greets them by name: "What will you build today, Sarah?" From there, they can browse six gradient-styled template cards covering common workflow patterns, use a search bar to filter templates, or hit "Start from Scratch" to begin with a blank canvas. Every workflow they create is persisted to a SQLite database and surfaces in a "Recent Workflows" section on the dashboard. Sessions last 24 hours with secure HTTP-only cookies, so closing the browser and coming back later drops you right where you left off. The whole experience is wrapped in a distinctive maroon aesthetic that makes it feel intentional and premium, not like another generic blue SaaS product.
How we built it
The frontend is React running on Vite at port 3000. The backend is Node.js with Express at port 3001, backed by SQLite via dorian.db which gets created automatically on first run. Authentication uses bcrypt for password hashing with a minimum 8-character requirement, and sessions are managed through secure HTTP-only cookies rather than JWTs or localStorage. The onboarding is a multi-step React component flow broken into individual step files like WelcomeStep.jsx for collecting email and password. The dashboard component lives in its own directory (components/dashboard/) with dedicated CSS for the Canva-inspired layout: a large centered title, a search bar, a 3x2 grid of template cards with CSS gradient backgrounds, and a recent workflows section below. API calls are centralized in a single services/api.js file that handles all communication between frontend and backend. Auth endpoints live in routes/user.js and the database config is isolated in config/database.js. We kept the architecture deliberately simple and file-based, no Docker, no cloud database, no third-party auth providers, so anyone can clone the repo, run npm install and npm run dev in two terminals, and be up in under 30 seconds.
Challenges we ran into
Cookie persistence across separate localhost ports was the single biggest time sink of the project. Early on, users would sign up, land on the dashboard, refresh the page, and get kicked back to the login screen. The issue traced back to how browsers handle SameSite cookie attributes and CORS between localhost:3000 and localhost:3001. Debugging this meant spending hours in the browser DevTools Application tab watching cookies appear and vanish. We also hit a "Dashboard cannot be loaded" error that turned out to be a race condition: the frontend was trying to render the dashboard component before the auth check API call had resolved, so it would briefly see an unauthenticated state and redirect. The fix was gating the dashboard render on the auth response. Then there was a bizarre double-text bug on the email input in WelcomeStep.jsx where every character appeared twice. That one traced back to a React state update firing on both onChange and a synthetic event from the custom input component. Small bugs, but the kind that erode user trust instantly if they ship.
Accomplishments that we're proud of
The dashboard just feels good. It is clean, spacious, and does not look like every other SaaS tool with a cramped sidebar and tiny cards. The large centered greeting, the breathing room around the template grid, and the maroon color palette give it a personality that most developer tools completely lack. We are proud that the full auth system, signup, bcrypt hashing, HTTP-only cookies, 24-hour session persistence, all works reliably without Firebase, Auth0, or any third-party provider. That is zero external auth dependencies. The onboarding flow moves a user from first visit to personalized dashboard in under 60 seconds across 7 steps, and it never feels rushed. We also kept the developer experience tight: the entire project is two directories (server/ and dorian-ui/), two terminal commands, and a SQLite file that creates itself. A health check endpoint at /api/health returns {"status":"ok"} so you can verify the backend in one curl command. No environment variables to configure, no database to provision, no deploy pipeline to set up before you can see it working.
What we learned
Session management is deceptively hard, especially with HTTP-only cookies across separate frontend and backend ports on localhost. We thought it would be a half-day task and it took almost two full days to get right. We also learned that the "feel" of a dashboard matters more than the feature count. Spending an extra afternoon on spacing, font sizing, the personal greeting, and the gradient cards changed how testers talked about the product. They stopped saying "it works" and started saying "this is nice." That shift matters. On the technical side, we gained a real appreciation for SQLite as a zero-config database for rapid prototyping. No connection strings, no running a separate database process, just a .db file that appears in your project directory. For a hackathon timeline, that simplicity is a superpower. We also learned to centralize API logic early. Having a single api.js service file instead of scattered fetch calls across components saved us from at least three or four duplicate bugs.
What's next for Dorian
The immediate next step is collaborative workflows so teams can build together in real time with shared cursors and live updates. After that, template sharing: imagine publishing your workflow to a community gallery and letting others fork and remix it. We are also exploring AI-assisted workflow generation where you describe what you want in plain language ("notify me on Slack every time a new row is added to my Google Sheet") and Dorian scaffolds the full workflow for you. On the infrastructure side, we want to migrate from SQLite to PostgreSQL for production use and add OAuth so users can sign in with Google or GitHub instead of just email and password. Longer term, the big goal is integrations with external services like Slack, Google Sheets, Notion, and GitHub so workflows are not just visual diagrams but actually execute and run on real data in real time.
Log in or sign up for Devpost to join the conversation.