Why We Built GritShip (And What We Left Out on Purpose)

We didn't build GritShip because we love project management. We built it because we hate it — and every tool we tried made us hate it more. This isn't a startup origin story about a whiteboard epiphany or a Y Combinator pitch deck. It's about a developer who spent more time configuring a PM tool than actually shipping work — and decided to start building a project management tool that doesn't waste your time.

If you're an indie hacker, a solo founder, a freelancer, or part of a small product team, you already know the feeling. You open your project management tool and it feels like filing taxes. Menus nested inside menus. Configuration screens for features you'll never use. A loading spinner while you wait for permission to drag a card from one column to another.

It shouldn't feel that way. It should feel like opening your code editor — fast, obvious, and out of the way.

That's GritShip — a project management tool for makers who'd rather ship than manage. Here's why it exists.

Most "why we built this" posts are thinly veiled product launches dressed up as stories. This one is different. We're going to tell you exactly what we built, what we deliberately didn't build, the technical constraints we chose, and who this tool is (and isn't) for. If you're an indie hacker or small-team developer evaluating GritShip, this post is the most honest picture you'll get.

---

The moment that started it

Every product starts with a frustration. Ours started with a 40-minute fight with a Jira board.

I used Jira for three years at a company of 200 engineers. Three full-time project managers maintained our board configurations. We had 14 custom fields per ticket. A weekly "backlog grooming" meeting lasted 90 minutes. I once spent 40 minutes figuring out which workflow transition would move a ticket from "QA Review" to "Ready for Deploy" — because someone had configured the transition to require a specific custom field that only appeared when another custom field was set to a particular value.

Forty minutes. To move a card.

That's not project management. That's bureaucracy cosplaying as productivity. And the worst part? Nobody thought it was broken. The project managers defended the complexity because it gave them "visibility." The developers tolerated it because they had no alternative. The entire team had normalized the idea that managing work should be almost as hard as doing the work.

Then I went solo.

Suddenly I was a team of one, building a product with no sprint cadence, no scrum master, and no one to sync with. I still needed to track what I was working on — but I needed approximately 3% of what Jira offered. The other 97% wasn't just unnecessary. It was actively hostile to getting work done. Every feature designed for a 200-person org was another menu item, another loading screen, another decision I didn't need to make.

I tried a GitHub Projects board. It was free and integrated with my repos, but the UI was clunky, the mobile experience was nonexistent, and creating an issue required more clicks than creating a pull request. I tried a plain markdown file in my repo — TODO.md with checkboxes. Honestly, that worked better than most tools. But it doesn't give you a visual board, and it breaks down the moment a second person joins the project.

So I tried the commercial tools. Over two years, I used seven different PM tools for real projects — not test drives, real shipped software. Here's what happened.

Trello was the first stop. It's simple. It's a board. Cards go in columns. For the first week, it felt like a relief after Jira. Then the cracks showed.

No keyboard shortcuts worth mentioning — you can't create a card without clicking. No way to filter by priority without installing a Power-Up. The free tier caps file uploads at 10MB and limits your automations. Larger boards — anything over 50 cards — start to lag visibly. Clicking a card opens it in a modal that takes 300-400ms to render on a fast connection. Try dragging 10 cards in quick succession and watch the UI struggle to keep up.

Trello is fine for planning a wedding or tracking a household move. It's not built for a developer who ships software daily and needs the tool to be invisible.

Notion was next. Notion can do anything. That's the problem.

I spent an entire weekend building a "perfect" project management database with relations, rollups, filtered views, and a custom status formula. I connected a tasks database to a projects database, created a sprint view, a backlog view, and a "this week" view with filters. It was beautiful — a masterwork of flexible infrastructure.

I never opened it again.

The second I tried to create a quick task on Monday morning, I had to decide which database it belonged in, which view to use, and whether to set 8 optional properties. My "quick capture" flow took 45 seconds per task. Multiply that by 15 tasks per day and you're spending 11 minutes just on data entry — into a system you built to save time.

Notion is a toolkit, not a tool. If you have to build your PM system before you can use it, the PM system has already failed.

Linear got closest. It's fast, keyboard-driven, and built for developers. I genuinely liked it. The keyboard shortcuts are excellent. The UI is clean. The engineering team clearly cares about performance.

But at $8 per user per month, a 5-person team pays $480/year for what is essentially a kanban board with excellent UX. Scale that to 10 people and you're at $960/year. And even Linear has features I'll never touch — cycles, project roadmaps, triage queues, SLA tracking, initiative hierarchies, and team-level analytics. It's built for funded startups with 15-person engineering teams and dedicated product managers, not for a solo dev or a small crew of makers shipping a side project on weekends.

Asana, Monday.com, ClickUp — I tried each for at least a month with real work. They all share the same DNA: built for teams of 50, marketed to teams of 5, priced to push you toward the enterprise tier.

Every one of them made me feel like I was using 10% of a tool that was 10x more complex than it needed to be. ClickUp alone has over 100 settings pages. Monday.com's free tier limits you to 2 users. Asana hides timeline view behind a paywall. All of them load slowly, especially on mobile. All of them have sidebar menus with subsections you'll never explore. All of them sent me a "you haven't logged in for 7 days" email, which is the PM tool equivalent of admitting you're not useful enough to open voluntarily.

Here's the paradox: every one of these tools has a "Simple" pricing tier. Every one of them calls themselves "easy to use." But simplicity isn't a pricing tier — it's an architecture. You can't bolt simplicity onto a product designed for enterprise complexity. The features are there, in the codebase, in the UI, in the loading time. Hiding them behind a paywall doesn't make them disappear. It just makes you aware of everything you're not using.

The realization was simple: no tool is built for the 1–10 person product team that just wants to ship. Every tool either starts simple and grows bloated (Trello → Trello Premium → Trello Enterprise), or starts opinionated and prices out individuals (Linear, Shortcut). The tools that stay free stay limited on purpose — the limits are the sales funnel, not a design choice.

I talked to other indie hackers and small-team developers about this. The pattern was universal. Nearly everyone I spoke to was either using a tool they didn't like, paying for features they didn't need, or had given up entirely and gone back to a spreadsheet or markdown file.

The problem wasn't that nobody could build a good PM tool. The problem was incentives. The PM tool market generates most of its revenue from enterprises. When your biggest customers need SSO, audit logs, and Gantt charts, that's what you build — even if 90% of your users are 3-person teams who need a fast board with keyboard shortcuts.

So we started building a project management tool ourselves. Not to disrupt the PM industry. Not to build a unicorn. To build the tool we wanted to use — a genuine project management tool for makers, not managers.

---

What we believe

Every product is a set of beliefs turned into code. Most companies bury their beliefs in a "values" page nobody reads or a culture doc that sounds like it was written by committee. We'd rather put ours in the product itself — in every pixel, every API response, every line of TypeScript. If you use GritShip for five minutes, you should be able to guess what we believe without reading this section.

But since you're here — here's what GritShip believes, and how we enforce each belief in our engineering process.

Speed is a feature

Not a nice-to-have. Not an aspiration. Not a bullet point on a marketing page. A feature — the most important one we ship. If you click a button and wait 400ms for a response, your tool is slow. Your brain notices the delay even when you can't articulate it. Your flow breaks. You start dreading the tool, and over time, you stop using it entirely.

GritShip has a hard constraint: every UI interaction responds in under 200 milliseconds. Not most interactions. Every single one. Creating a task, dragging a card, opening a detail panel, adding a comment, filtering by label, switching projects, toggling a sidebar — all under 200ms. We enforce this the same way we enforce type safety: it's a gate in our build process. If a feature can't meet the threshold, it doesn't ship. No exceptions, no "we'll optimize it later."

This isn't marketing copy. It's an engineering decision with real, painful trade-offs. We use optimistic updates for every mutation — your UI changes instantly while the server catches up in the background. We keep our initial JavaScript bundle under 100KB gzipped. We reject any npm dependency over 10KB without explicit justification. Every one of these decisions limits what we can build. That's the point. The limits are the product.

Speed compounds. A tool that's 200ms faster per interaction saves you minutes per day — and more importantly, it never breaks your flow. You never think "I'll batch these updates later because the tool is slow." You update in real time because the tool lets you. That's the difference between a tool you tolerate and a tool you actually use.

Less is more

Every feature you add is a feature someone has to learn. Every button is a decision someone has to make. Every setting is a question someone has to answer. The cost of a feature isn't just the engineering time to build it — it's the cognitive load it places on every user, every time they open the app, forever.

Most PM tools compete on feature count. They want the longest column in the comparison chart. But for the makers and builders we're building for, more features means more friction. A solo developer doesn't need 47 features — they need 5 features that work perfectly, load instantly, and never get in the way.

GritShip project management is intentionally smaller than every competitor. Not because we're lazy or under-resourced — but because we think a PM tool that does less, done perfectly, is worth more than a PM tool that does everything, done adequately.

We'd rather do 5 things perfectly than 50 things adequately. GritShip has boards, tasks, columns, labels, and comments. That's it. No Gantt charts. No time tracking. No custom workflows. Not because we can't build them — but because we believe they make the tool worse for the people we're building for.

The best tools are the ones where you never think about the tool. You think about the work. GritShip's goal is to disappear — to be so fast and so obvious that you forget you're using a PM tool at all.

Free should mean free

Not "free trial." Not "free for up to 3 projects." Not "free but we'll watermark your exports and nag you to upgrade every time you log in."

Free as in: you sign up, you use it, it works, nobody asks you for a credit card. The core product — boards, tasks, collaboration for small teams — is free. Not because we're generous, but because we think the best business model for a tool like this is to earn money from power users who genuinely need premium capabilities, not to charge everyone for the basics that should be table stakes.

We looked at how other tools define "free" and it's almost always a euphemism for "limited." Trello's free tier caps your automations and file uploads. Asana's free tier hides timeline view and custom fields. Monday.com's free tier limits you to 2 seats. These aren't free products — they're paid products with a demo mode. The "free" label is a marketing decision, not a product decision.

GritShip's free tier is the product. You get boards, tasks, columns, labels, comments, keyboard shortcuts, and real-time collaboration. No feature is locked behind a "Upgrade to Pro" modal that appears the moment you try to do something useful. If we ever add a paid tier, it'll be for genuinely premium features — not for unlocking things you expected to have in the first place.

The math is simple: if GritShip's free tier is good enough that most small teams never need to pay, we've built the right product. Revenue should come from users who genuinely need more — not from users who are frustrated into upgrading.

---

What we left out on purpose

This is the section most companies wouldn't write. It might be the most important section in this entire post.

It's a list of features GritShip intentionally doesn't have — not because we haven't thought about them, but because we thought about them carefully and said no.

Building a project management tool is an exercise in saying no. The feature requests never stop. Every user has a different "must-have." Every competitor adds a new checkbox to the comparison sheet. If you say yes to all of them, you end up with ClickUp — a tool that does everything and feels like nothing. A tool where finding the feature you need is harder than doing the work manually.

We decided early on that GritShip would be defined as much by what it doesn't do as by what it does. That means having a clear, articulate rationale for every feature we reject — not just "we haven't built it yet," but "we've decided not to build it, and here's exactly why."

If you disagree with any of these decisions, that's okay. It means GritShip might not be the right tool for you — and knowing that upfront saves everyone time.

Every "no" below is a product decision. Here are ours.

No Gantt charts

You're not a general contractor scheduling concrete pours across a 14-month highway project. You're a developer shipping software. Gantt charts exist because enterprise project managers need to visualize complex dependencies across 40-person teams with 18-month timelines and regulatory deadlines. If your project has 3 people and ships in weeks, a Gantt chart is a screenshot you'll take once, share in Slack, and never look at again.

We've watched teams spend hours building beautiful Gantt charts that are outdated by the time they're shared. The dependency arrows look impressive in a presentation. They communicate nothing that a 5-minute standup wouldn't handle better for a team under 10.

If your entire team fits in one room, you don't need a visual representation of who depends on whom. You already know. And if your project timeline is "ship it as soon as it's ready," a Gantt chart is decorating a deadline that doesn't exist.

No sprint planning

Sprints exist to synchronize teams. They solve a real coordination problem — when 20 engineers need to deliver a coherent release, a fixed two-week time-box creates shared expectations and forces priority decisions. But when your team is 3 people sitting in the same room (or the same Discord channel), you don't need a formal ceremony to decide what to work on next. You need a list and a conversation.

Sprint planning for a 3-person team is like scheduling a formal meeting to decide what's for dinner. The overhead exceeds the value. The ceremony replaces the judgment.

Most sprint planning for small teams devolves into the same pattern: you estimate tasks in story points, the estimates are wrong (they always are), you commit to a sprint scope, you don't finish it (you rarely do), and you spend the retrospective discussing why the estimates were wrong. Then you do it again two weeks later. The process exists to create the appearance of predictability for stakeholders. When there are no stakeholders — when you're the founder, the developer, and the user all at once — the process serves no one.

GritShip gives you the list. You handle the conversation.

No time tracking

Time tracking measures input. We think makers should measure output. How many hours you spent on a feature matters to your client's billing department, not to your product. Nobody's startup succeeded because the founder tracked 8.5 hours per day in a PM tool. Products ship because people solve problems, not because they log time.

If you need time tracking for client billing, use Toggl or Harvest — they're excellent at that specific job and have spent years perfecting it. We're not going to build a mediocre version of a time tracker inside a project management tool. That's how feature bloat starts: you add a "simple" timer, then clients want reports, then reports need CSV export, then exports need formatting options, and suddenly your PM tool is 20% time-tracking code that 90% of users never touch. We'd rather integrate with Toggl than replace it.

No custom workflows

Custom workflows sound like a feature. They're actually a trap. "To Do → In Progress → Code Review → QA → Staging → Ready for Deploy → Deployed → Verified → Closed" is not a workflow. It's a bureaucratic checkpoint system that creates the illusion of process while adding real friction to every task transition.

The dirty secret of custom workflows is that most teams create them once during a "process improvement" initiative, realize within a month that the workflow doesn't match how work actually flows, and then either ignore it or spend more time maintaining the workflow than following it. GritShip gives you columns. You name them whatever you want. You drag cards between them. That's the workflow. If your process changes next week, rename a column. It takes 2 seconds, not a settings page with validation rules.

No AI features

Your project management tool should be fast, not smart. We're not going to auto-generate task descriptions, suggest priorities with machine learning, or summarize your standup with GPT. These features sound impressive in a product demo, add 200KB to your JavaScript bundle, and answer a question nobody was asking: "What if my kanban board could think?"

We'd rather spend engineering time making the board 50ms faster than making it 50% smarter. AI features in PM tools are, right now, a marketing checkbox — something to mention in a Product Hunt launch or put on the enterprise comparison sheet, not something that changes how a 3-person team ships software.

When AI genuinely improves project management for small teams — not "summarize my sprint" but actually makes shipping faster — we'll reconsider. Until then, we'll invest that engineering effort where it matters: performance, reliability, and simplicity.

The discipline of saying no is hard. Every feature on this list is something real users have asked for. Some of them are features we personally wanted to build — custom workflows, in particular, are an interesting engineering challenge. But building a project management tool isn't about what's interesting to build. It's about what's useful to use. And for the makers, indie hackers, and small teams we're building for, fewer features done well beats more features done adequately.

---

The technical constraints we chose

Most companies talk about their tech stack in a blog post and call it transparency. We'd rather talk about our constraints — the things we chose not to allow ourselves to do. The stack is just the implementation detail. The constraints are the product.

Building a project management tool that feels instant requires a different kind of engineering discipline than building one that merely works. It's not about using the right framework — it's about refusing to compromise on measurable performance thresholds, even when doing so makes development slower and harder.

Here are the specific, measurable constraints we enforce on every line of code that ships.

Every UI interaction under 200ms

This is the constraint that shapes everything else. When you set a 200ms ceiling on user-perceived latency, it forces a specific architecture. You can't round-trip to the server for every click. You can't render complex layouts synchronously. You can't load a 400KB charting library for a feature someone uses once a month. You can't add "just one more" CSS animation that takes 350ms to complete.

The 200ms number isn't arbitrary. Research on human perception shows that delays under ~200ms feel "instant" — the user perceives the response as happening simultaneously with their action. Above 200ms, the brain registers a gap. Above 500ms, the user becomes consciously aware of waiting. We want GritShip to always feel instant. That means every interaction must complete in under 200ms, measured from the user's click to the visual update on screen.

We use optimistic updates everywhere. When you create a task, the UI updates instantly — the task card appears in the column, the card is interactive, you can start typing a description. The POST request to PostgreSQL happens in the background via our Zustand store. If the server rejects the mutation (which is rare — usually a network issue), we roll back the local state and show a toast. The user's experience is that every action is instantaneous, because from their perspective, it is.

This pattern is harder to build than traditional server-first rendering. It requires careful state synchronization, conflict resolution for real-time collaboration, and robust error handling for every possible network failure. We chose the harder path because the result is a tool that feels like a native desktop app, not a web page waiting for permission from a server 200ms away.

PostgreSQL via Supabase for real-time

Every PM tool needs real-time updates — when your teammate moves a card, you should see it move on your board without refreshing. Most tools poll the server every few seconds, which wastes bandwidth and still creates a noticeable delay. GritShip uses Supabase Realtime over WebSockets. When a row changes in PostgreSQL, every connected client gets the update within milliseconds, not seconds. No polling. No stale data. No "click refresh to see changes."

This architecture decision also means we get conflict resolution for free — the database is always the source of truth, and real-time subscriptions ensure every client converges to the same state. When two people move the same card at the same time, one update wins at the database level, and both clients immediately see the consistent result.

Initial JS bundle under 100KB gzipped

GritShip is built on Next.js 15 with the App Router. We use React Server Components by default — client JavaScript only loads for components that genuinely need interactivity (drag-and-drop, real-time subscriptions, keyboard shortcut handlers). Modals, the command palette, and settings panels are all lazy-loaded with React.lazy() and next/dynamic. They don't add a single byte to the initial page load.

We check bundle size on every build. If a pull request increases the bundle by more than 5KB without a written justification, it gets rejected. Not "discussed." Not "we'll optimize it later." Rejected outright. The constraint is non-negotiable because the moment you start making exceptions is the moment your 100KB bundle becomes 200KB. We've seen it happen at every company we've worked at. It always starts with "just one more dependency."

No dependency over 10KB without justification

Before adding any npm package, we check its size on Bundlephobia. If it's over 10KB gzipped, it needs an explicit justification in the pull request: what problem does it solve, why can't we solve it with less code, and what's the realistic alternative?

This rule has saved us from bloat dozens of times. It's why we use @atlaskit/pragmatic-drag-and-drop instead of heavier drag-and-drop libraries — it does exactly what we need at a fraction of the bundle cost. It's why we don't use a date picker library — a well-styled HTML date input handles 95% of use cases without adding 12KB to the bundle. It's why our toast notifications are a custom 40-line component, not a 15KB third-party library with 30 configuration options we'd never use.

Optimistic updates everywhere

Every mutation in GritShip follows the same pattern: update the local Zustand store immediately, fire the API request to the server in the background, and roll back on failure with a user-visible toast notification. This architecture means the UI never waits. Drag a card to a new column — it moves instantly. Edit a task title — the text updates as you type. Add a label — it appears before the HTTP request leaves your browser.

The trade-off is real engineering complexity. We have to handle edge cases that simpler architectures avoid entirely: what happens when two people move the same card simultaneously? What if the server is unreachable for 5 seconds — do we queue the mutations or discard them? What if an optimistic update from user A conflicts with a real-time Supabase update from user B? We've solved each of these cases, and the solutions are completely invisible to the user. That's the goal — hard engineering so the user experience feels effortless.

Server Components by default

GritShip uses React Server Components for every page and component that doesn't need client-side interactivity. Your project list, workspace settings, profile page — all rendered on the server, zero client JavaScript. The "use client" directive only appears on components that genuinely require it: the board view (drag-and-drop), the task detail panel (real-time comments), and keyboard shortcut handlers.

This isn't just a bundle size optimization. It's a fundamental architectural choice. Server Components mean faster initial loads, better SEO, and less JavaScript for the browser to parse. Most pages in GritShip load faster than you can blink — because there's no JavaScript to download, parse, and execute before the content appears.

---

Who GritShip is for (and who it isn't)

We'd rather lose a potential user by being honest than gain one by being vague. GritShip project management is built for a specific kind of team — and we think being clear about that makes the product better for everyone.

GritShip is for:

• Solo developers building side projects, indie apps, or client work. You need a place to track tasks without a 45-minute setup process. Open a board, create some tasks, start shipping. No configuration wizards. No "workspace setup" flow with 12 steps. Just a board.
• Freelancers juggling 2–3 client projects simultaneously. You need boards you can switch between in one click, not a portfolio management dashboard with resource allocation charts and utilization reports.
• Small product teams (2–10 people) shipping software together. You need shared visibility into who's working on what, not role-based access control with 6 permission levels, an admin console, and an audit log.
• Indie hackers and makers who measure progress in shipped features, not story points or velocity charts. Who'd rather spend 30 seconds creating a task than 5 minutes filling out 12 required fields.
• Anyone who has tried 5 PM tools and still uses a markdown file because nothing was fast enough and simple enough to justify the context switch away from their editor.

If you've ever felt like your PM tool has more features than your actual product — GritShip is for you.

Think of it this way: if your entire development team can fit on a single Zoom call without anyone getting lost, you're GritShip's core audience. We built every feature, every keyboard shortcut, and every interaction with that exact team size in mind.

GritShip is not for:

• Enterprises that need SSO, SAML, audit logs, compliance certifications, and a 40-page security questionnaire response. We're not building those features. Not because they're bad — but because building them changes what the product is. It changes who you hire, what you prioritize, and how you think about the tool every day.
• Teams that need Gantt charts, resource allocation, and capacity planning. You need a different category of tool entirely. Microsoft Project, Smartsheet, or Monday.com will serve you better. That's okay — we'd rather you use the right tool than struggle with the wrong one.
• Project managers who manage projects full-time. GritShip is for people who manage projects part-time because their real job is building the thing. If project management is your full-time job, you need more functionality than we offer, and we're okay with that.
• Anyone who wants AI-generated task suggestions, automated workflows, or chatbot integrations. We're not putting a language model in your kanban board.

We don't see these limitations as weaknesses. They're the reason GritShip is fast, simple, and free. Every enterprise feature we don't build is engineering time we spend on making the core experience better for the people who actually use it.

GritShip project management isn't trying to be everything to everyone. It's trying to be the best tool for one specific audience: small teams and solo builders who want to ship. That focus is what makes it different from tools that try to serve a 3-person startup and a 300-person enterprise with the same product.

---

What's next

We're not going to show you a 12-month roadmap with swimlanes and milestones. That would be ironic. Here's what we're building next, in plain language — no timelines, no promises, just direction.

Trello import — If you have years of cards in Trello, you should be able to bring them over in one click. We're building a direct importer that maps Trello boards, lists, and cards to GritShip projects, columns, and tasks. No manual CSV export required. No field-mapping wizard. Connect your Trello account, pick a board, and it's done. Your labels, descriptions, and comments come with it.

File attachments — Sometimes you need to attach a screenshot, a design file, or a spec document to a task. We're adding file uploads backed by Cloudflare R2, with a drag-and-drop interface that doesn't slow down the board. Files attach directly to tasks — not to some separate "documents" section you'll forget about. We're targeting upload-to-visible in under 2 seconds for typical images.

Calendar view — Some people think in dates, not columns. We're adding an optional calendar view for tasks with due dates. You'll never see it unless you want it, and it won't add a single byte to the bundle until you open it — it'll be lazy-loaded, following the same performance constraints as everything else in GritShip.

API access — We want GritShip to play well with your existing workflow. A REST API is on the roadmap for developers who want to create tasks from scripts, integrate with CI/CD pipelines, or build custom integrations. It'll be free, well-documented, and designed to be simple enough that you can write an integration in an afternoon.

Mobile-optimized experience — GritShip is a web app, not a native app. But we're making sure the mobile experience is fast and usable — responsive layouts, touch-friendly drag targets, and the same sub-200ms interactions on your phone as on your laptop. No native app download required. Open the URL and you're in.

But here's the thing that won't change: the core philosophy. Speed first. Simplicity first. Every new feature will meet the same constraints — under 200ms, under 100KB, no unnecessary complexity. If a proposed feature would make the board 15% slower for everyone, it doesn't ship — even if 30% of users are requesting it. We'd rather ship three features well than ten features that make the tool 20% slower and the interface 30% more confusing.

We're building GritShip in public. That means you can see what we're working on, tell us what you need, and hold us accountable when we get something wrong. This project management tool for makers is being built by makers — and we think that's the only way to get it right.

If you're an indie hacker or developer evaluating project management tools, we hope this post gave you an honest picture of what GritShip is and isn't. There's no "book a demo" button. There's no sales team. There's just the product — fast, simple, and built for people like us.

But here's the thing that won't change: the core philosophy. Speed first. Simplicity first. Every new feature will meet the same constraints — under 200ms, under 100KB, no unnecessary complexity. We'd rather ship three features well than ten features that make the tool 20% slower and the interface 30% more confusing.

GritShip is a project management tool for makers — people who build things and need to track their work without the overhead of tools designed for organizations 10x their size. It's opinionated, fast, and free.

If that sounds like the kind of tool you've been looking for, give GritShip a try. It takes less than 60 seconds to go from signup to your first task. No credit card. No onboarding wizard. No "book a demo" button. No 14-day trial clock ticking in the corner.

If it doesn't sound like your thing — genuinely, no hard feelings. We didn't build GritShip to replace every PM tool. We built it to be the best option for a specific group of people: developers, freelancers, and indie hackers who want to ship, not manage. If that's you, we'd love to have you.

And if you have feedback, feature requests, or just want to tell us what we got wrong — reach out. We're building this in public, and the people who use GritShip shape what it becomes.

We didn't build GritShip because the world needed another PM tool. There are hundreds of PM tools. We built it because none of them were built for us — and we suspect none of them were built for you, either.

The best project management tool for makers is the one that gets out of the way and lets you make things. That's what GritShip is. That's what it will always be.

---

Frequently asked questions

What is GritShip?

GritShip is a lightweight, web-based project management tool built specifically for solo developers, freelancers, and small product teams (2–10 people). It focuses on speed, simplicity, and a board-based workflow without the feature bloat found in enterprise PM tools. Every interaction responds in under 200ms, and the core product is free.

Is GritShip free?

Yes. The core product — boards, tasks, columns, labels, comments, and team collaboration — is free with no time limit, no credit card required, and no artificial restrictions designed to push you toward a paid tier. We plan to offer a paid plan for power users who need premium features, but the free tier is a fully functional product, not a demo.

Who is GritShip for?

GritShip is built for indie hackers, solo developers, freelancers, and small product teams of 2–10 people. If you spend most of your time building software and need a fast, simple place to track tasks without configuring workflows or sitting through sprint ceremonies, GritShip is for you. It's not designed for enterprises or teams that need Gantt charts, resource planning, or compliance features.

How is GritShip different from Trello?

Both are board-based, but GritShip is built for developers and makers who ship software. It's keyboard-driven, responds to every interaction in under 200ms (Trello can lag noticeably on larger boards), and doesn't gate useful features like filtered views or priority labels behind paid Power-Ups. GritShip also keeps its interface minimal — no stickers, no backgrounds, no butler automations — just a fast board for shipping.

How is GritShip different from Linear?

Linear is an excellent product, and it inspired parts of GritShip's design philosophy. The key differences are: GritShip is free for small teams (Linear starts at $8/user/month), GritShip is intentionally simpler (no cycles, triage, SLAs, or project roadmaps), and GritShip's initial JS bundle is under 100KB gzipped. If you're a funded startup with 15+ engineers, Linear is probably the better choice. If you're a solo dev or a team under 10, GritShip gives you what you need without paying for what you don't.

Does GritShip have an API?

Not yet, but an API is on the roadmap and will be free to use when it ships. Our priority right now is making the core product fast and reliable. When we do ship the API, it will be a straightforward REST API with clear documentation — no GraphQL complexity, no rate limits designed to push you to a higher pricing tier.

Will GritShip always be free?

The core product will always be free. We may introduce a paid tier in the future for premium features like advanced integrations, increased file storage, or priority support. But the board-based project management that GritShip is built around — tasks, columns, labels, comments, and real-time collaboration — will remain free. We're building a free product with optional upgrades, not a free trial.

What tech stack does GritShip use?

GritShip is built with Next.js 15 (App Router), TypeScript in strict mode, PostgreSQL via Supabase, Tailwind CSS for styling, Zustand for client-side state management, and Prisma as the ORM. Real-time collaboration uses Supabase Realtime over WebSockets. The app is hosted on Vercel. We enforce a strict performance budget: every UI interaction must respond in under 200ms, the initial JS bundle must stay under 100KB gzipped, and no npm dependency over 10KB is allowed without explicit justification.