sifty
Scope Clarity for FreelancersA lightweight scoping tool that makes project boundaries visible before they become disputes. Built for freelancers and small studios who need clarity without complexity.
Sifty (sifty.app) is a project scoping and tracking tool both designed and built by me (with the assistance of AI tools) from initial research to full production code. The goal was not to recreate what already exists in management tools like Trello, but to create a simple and efficient tool that helps freelancers constrain scope boundaries, without adding large overhead to their existing workflow.
THE PROBLEM
In freelance work, scope creep is one of the most common sources of general conflict. This isn't due to intentional bad faith actors, but because the client and freelancer perspective of an assignment will always be fundamentally different. As the project progresses, that difference can easily snowball and present themselves as constant disputes against deliverables, timelines, costs, and more.
Invisible boundaries
When setting up a new project, scope can be defined in a multitude of ways. It can be a well documented proposal email, a long chain of DMs, or even something as informal as a short facetime call. When operating from such an informal medium of communication, agreements can easily be remembered (or digested) very differently by each participating member. And oftentimes there is no singular artifact to reference.
Tools that manage tasks, not scope
When looking at what's already on the market, its easy to point to tools like Trello, Asana, and Notion as products that have already “solved” these issues. These products however are largely focused on product management, and often do not act as client-facing solutions for a problem like scope creep. Scope there is an afterthought buried in a field of busy notes, if addressed at all.
Documentation friction
Freelancers don't like heavy documentation work. When clients shift expectations, this shift needs to be documented and preserved immediately. Existing tools require navigating to a project, finding the right sections, filling out forms, etc.. The overhead in initializing a simple task means most changes often go unrecorded.
RESEARCH
Before designing anything, I looked at how freelancers currently handle scoping and what tools already exist. The landscape is full of project management tools (Trello, Asana, Notion, Basecamp), but they all treat scope as one feature among many. Scope lives in a notes field, a description box, or a shared doc that nobody updates after week one. None of them make scope boundaries the primary organizing principle.
25-40%
Average budget overrun caused by scope creep
42%
Of scope creep cases traced to insufficient requirement analysis
23%
Of digital projects have clearly defined acceptance criteria
I also looked at how freelancers talk about scoping problems in practice. The pattern was consistent: unclear briefs, no documentation of verbal changes, revision limits that were never formally agreed on, and clients who genuinely believed something was included because nobody wrote down that it wasn't. The problem wasn't bad faith on either side. It was that informal communication doesn't leave a paper trail, and by the time a disagreement surfaces, there's nothing to point back to.
QUESTIONS THAT SHAPED THE DESIGN
“What information do freelancers wish they had before starting work?”
“How do they currently document requirements and changes?”
“Where does the disconnect between client and freelancer actually begin?”
“What level of effort can realistically be expected from clients?”
THE OPPORTUNITY
While existing tools addressed task management or team collaboration, none focused specifically on making scope boundaries the primary interface. There was an opportunity to build something that sits alongside a freelancer's informal workflow (Slack messages, emails, quick calls) and turns those scattered decisions into a visible, shared record. Not a project management suite. A scoping tool.
I looked at Trello, Asana, Notion, and Basecamp specifically through the lens of scope visibility. All four are strong task management tools. But in every one of them, scope definition is buried: a description field in Trello, a page property in Notion, a message thread in Basecamp. There's no persistent, visible boundary between “what we agreed to build” and “what we didn't.” That gap was the opportunity.
DEFINING SCOPE
To validate the core concept quickly, cutting aggressively was essential. The guiding principle: do one thing exceptionally well rather than many things adequately.
INCLUDED
- • Project brief with deliverables and timeline
- • Explicit “out of scope” section, making exclusions as visible as inclusions
- • Revision counter per deliverable with visual progress
- • Vertical timeline as the primary (and only) interface
- • Quick-add for logging changes in under 30 seconds
- • Read-only client view via shareable link
- • Light and dark theme support
DELIBERATELY EXCLUDED
- • Client-side editing or collaboration, which keeps the freelancer in control as project lead
- • Payment processing, just terms documentation, not transactions
- • Team management or resource allocation, built for solo practitioners, not enterprises
- • Real-time collaboration, which would require auth, sync, conflict resolution, delaying launch for a feature that doesn't serve the core use case
- • Client-initiated revision requests, since shifting control to clients creates obligation, undermining the freelancer-first model
SOLUTION DESIGN
Timeline as the primary interface
The main challenge was choosing how to organize project information. Dashboard views and tab-based layouts are standard in project tools, but freelancers checking in mid-project think chronologically: “What's next? What did we finish? When is this due?”
The timeline was designed as the only primary view. Not one tab among many, but the entire interface. Project details, exclusions, and the changelog are accessed via expandable overlays from the timeline context.
I considered a horizontal Gantt chart initially, which is standard in project management. It follows the natural reading direction left-to-right and can show parallel work tracks. But this already presents a number of issues. Horizontal timelines require horizontal scrolling. From a mobile-first viewpoint, this is already a failure. They also have a more corporate feel, where this project is intended to appeal to individuals. A vertical timeline follows the current style in how content is consumed (social media applications), and would provide a more appealing fit to freelancers.
This meant sacrificing a birds-eye dashboard view of all deliverables at once. But for freelancers managing 3–10 projects with sequential workflows, the chronological view matched their mental model more naturally than a grid of cards.
Making exclusions visible
Most tools only track what you're building. Sifty makes what's NOT included equally prominent. The “out of scope” section uses a badge showing the count of excluded items, and makes itself persistent on the client side. The utility of explicitly directing what is completely out of scope for the project helps solve most creep problems before they even have the chance to manifest.
A simpler option could have been a single “notes” field where freelancers could type whatever they wanted about scope. But unstructured notes don't create accountability. A dedicated exclusions section with a visible item count turns “I think we mentioned that wasn't included” into “there are 4 items explicitly listed as out of scope, and here they are.” No room for arguments.
Surfacing exclusions this prominently risks feeling negative, like leading with limitations. But in freelance work, the conversations that go wrong are almost always about what someone assumed was included. Making exclusions visible up front prevents those conversations entirely.
Client view: read-only by design
Clients access their project via a separate shareable link. Rather than disabling edit controls, they were removed entirely. No greyed-out buttons, no “you don't have permission” tooltips. The client view is a clean, read-only document.
The alternative was showing disabled controls so clients could see the full interface. But greyed-out buttons create confusion (“why can't I click this?”) and imply the client should have editing power. Removing UI elements entirely creates a professional, published-document experience where the freelancer's role as project lead is architecturally reinforced.
Form design: validation on submit
The project creation form collects 9 fields (5 mandatory, 4 optional behind toggles). A critical design question was when to show validation errors.
On-blur validation catches errors early but feels aggressive. Red borders appearing while you're still filling out the form. On-change validation is worse, flagging errors mid-keystroke. The choice was to validate only on submit: errors appear when the user tells us “I think I'm ready,” not while they're still thinking. After the first submit attempt, fields update in real-time as the user corrects them.
This means a user could fill out the entire form before seeing any errors. But respecting user agency, letting them work at their own pace without the interface presuming they're making mistakes. That produces a calmer, more confident interaction. The real-time feedback after first submit catches the practical concern.
Quick-add: 30-second documentation
The biggest barrier to consistent scope documentation is friction. When a freelancer finishes a client call where something changed, they need to capture it immediately, not navigate through menus and fill out detailed forms. The Quick Add button is always visible and opens a contextual mini-form: select the type (deliverable, milestone, scope change), fill in the essentials, and it's on the timeline in under 30 seconds. Details can be added later, but the facts are preserved now.
The alternative was a full form that captures everything at once: description, category, time impact, cost impact, approval status. That's thorough, but it takes 3-5 minutes per entry. For a freelancer who just got off a call and has another one starting in 10 minutes, that's too much. The Quick Add approach treats initial capture and detailed documentation as two separate actions, and only the first one needs to be fast.
Quick capture means incomplete entries. A 30-second log won't have the detail of a carefully written scope amendment. But incomplete documentation that actually gets created is far more useful than detailed documentation that doesn't exist because the friction was too high.
RESPONSIVE DESIGN
Freelancers check project status on their phone between client meetings. The mobile implementation isn't a compressed desktop. It's a separate experience designed for viewing and quick actions. The timeline stem renders at 65% scale while task cards remain full-size, because the timeline is contextual decoration but the cards contain content users need to read and tap.
Complex editing (rearranging timeline items, detailed brief changes) is desktop-only. Mobile users can view everything and mark items complete, but deep project management happens at a keyboard. This constraint kept the mobile experience focused instead of cramped.
BUILT WITH
For the backend, Supabase with PostgreSQL was implemented for secure project storage and consistent data updates. Radix UI was used to implement clean primitives that allowed for further design control while keeping our design language grounded. The entire application was built by leveraging Claude Code for implementation with myself acting as the design director, writing specifications as detailed task documents
Sifty is currently live and in active use. I plan on continuing live development on the website in my free time. Future updates will include further debugging for a smoother experience, enhanced dependency tracking, image hosting, a more fleshed out dating system, and much more.
If I could go back and redo any part of the project, I would invest more time in user testing before launch. While the research phase was extensive enough to properly outline necessity and guide decision making, my user base for actual product testing was fairly limited. Having the prototype broadcast to more freelancers earlier would have helped identify usability issues much sooner, and would likely aid in identifying additional markers that may still not be present.