The anti-Jira dev project setup: organized in 10 minutes
Every developer who has set up a Jira project from scratch knows the ritual. You want to track bugs, features and tasks. Instead, you're configuring issue type schemes, workflow schemes, screen schemes, permission schemes and notification schemes. An hour in, you're reading Atlassian documentation about how schemes link to other schemes. You haven't created a single issue yet.
A simple project management setup for developers without Jira means creating a project with a few issue types, a handful of statuses, one or two custom fields and a board view. No schemes. No admin panel. No meetings about configuration. You define what matters to your project and start working.
TL;DR: Setting up a dev project in Eigenfocus takes about 10 minutes. Three issue types, five statuses, two custom fields, one board. In Jira, the same outcome requires configuring multiple schemes, screens and permissions. This post walks through both setups side by side.
What does a simple project management setup for developers actually need?
Most software development projects run on the same basic structure:
- Issue types to separate bugs from features from tasks
- Statuses to track where each issue sits in your workflow
- A board to visualize everything at a glance
- A field or two to capture priority or effort
That's it. You don't need sprint planning, story point calculations, epics-within-epics or velocity charts to ship working software. You need to know what work exists, who's doing it and where it stands.
The problem is that most project management tools make you configure far more than this before you can start. Jira is the obvious example, but it's not the only one. The pattern is the same: admin-level configuration that solves enterprise problems you don't have.
The Jira setup: what happens before you create your first issue
Let's walk through what it actually takes to set up a Jira project for a development team. Not the "create a project from a template" shortcut, but what you need to touch when the defaults don't fit your workflow.
Issue type schemes
Jira ships with default issue types (Story, Task, Bug, Epic, Sub-task). If those work for you, great. If you want to rename them, add a new type or remove one you don't need, you're editing the issue type scheme. That's a global setting. Changes affect every project using that scheme unless you create a new one.
Workflow schemes
Each issue type can have its own workflow. Workflows define the statuses an issue moves through and the transitions between them. Want "In Review" as a status? You need to add it to the workflow, define which statuses can transition to it and which statuses it can transition to. Then you link the workflow to your issue type through the workflow scheme.
Screen schemes
When someone creates an issue, edits an issue or transitions an issue, Jira shows different screens. Each screen defines which fields appear. To control what fields show up where, you configure screen schemes and issue type screen schemes. Yes, those are two different things.
Permission schemes
Who can create issues? Who can assign them? Who can transition them? Each action has its own permission entry. Permissions are grouped into a permission scheme, which is applied to the project. Modifying permissions means understanding roles, groups and application access.
Field configurations
Custom fields in Jira are global by default. If you add a "Sprint Goal" field, it shows up in every project unless you create a field configuration scheme to control visibility per project. Adding a field is easy. Making it appear only where you want it is not.
The meeting tax
In practice, this configuration rarely happens solo. Someone proposes a workflow change, the team discusses it, the Jira admin implements it, the team tests it. For a new project setup with custom needs, two or three meetings are common before the first issue gets created.
None of this means Jira is bad software. It's built for organizations that genuinely need this level of control. But if your team has 5-20 people working on a single product, you're paying a configuration tax for problems you'll never have.
The Eigenfocus setup: organized in 10 minutes
Here's the same project set up in Eigenfocus. Same goals: track bugs, features and tasks with clear statuses and a couple of custom fields.
Step 1: Create the project (30 seconds)
Click "New Project," give it a name. Done. No templates, no schemes, no admin panel.
Step 2: Define your issue types (1 minute)
Go to project settings and create three issue types:
- Bug for defects
- Feature for new functionality
- Task for everything else (tech debt, docs, infrastructure)
Issue types are per-project. They don't affect other projects. If you later want to add "Spike" or "Chore," just add it. No scheme to update.
Step 3: Set your statuses (2 minutes)
Create five statuses that match how your team actually works:
- Backlog for work that's been identified but not started
- To Do for work that's ready to pick up this week
- In Progress for active work
- In Review for pull requests and code review
- Done for completed work
Statuses are also per-project. Rename them anytime. Reorder them by dragging. No workflow transitions to configure. An issue can move from any status to any other status. If you want to learn more about designing workflow stages, read our guide on how to set up a project workflow from scratch.
Step 4: Add two custom fields (2 minutes)
Create a Priority field (single select: Low, Medium, High, Critical) and an Effort field (single select: S, M, L, XL). Both show up on your board cards as colored badges. You pick the colors per option.
Custom fields belong to the project. No global configuration, no field configuration schemes. Just add the field and start using it. For ideas on which fields work well for development projects, check out custom fields for project management.
Step 5: Open your board (1 minute)
Your board is automatically grouped by status. Cards show the issue type, assignee, priority badge and effort badge. Drag issues between columns as work progresses.
If you later need a second perspective, create another view. Group by assignee to see workload distribution. Group by label to see work by area (Frontend, Backend, Infrastructure). Each view shows the same data from a different angle.
Step 6: Create your first issues (4 minutes)
Add a few real issues. Something like:
- Feature: User authentication flow (Priority: High, Effort: L)
- Bug: Login redirect fails on Safari (Priority: Medium, Effort: S)
- Task: Set up CI pipeline (Priority: High, Effort: M)
- Feature: Dashboard analytics page (Priority: Medium, Effort: XL)
- Task: Update dependency versions (Priority: Low, Effort: S)
That's your project. Five statuses, three issue types, two custom fields, one board. Ten minutes of actual work.
See how Eigenfocus pricing works.
How does a simple project management setup compare between Jira and Eigenfocus?
Here's what you configure to get the same result in both tools:
| Setup step | Jira | Eigenfocus |
|---|---|---|
| Create project | Choose template, configure project type | Click "New Project," name it |
| Issue types | Edit issue type scheme (global) | Add types in project settings (per-project) |
| Statuses | Edit workflow, link via workflow scheme | Add statuses in project settings (per-project) |
| Transitions | Define allowed transitions per status pair | Not needed. Any status can move to any status |
| Screens | Configure screen scheme + issue type screen scheme | Not applicable. One consistent issue view |
| Permissions | Configure permission scheme with roles | Invite members, assign roles per project |
| Custom fields | Create globally, manage visibility via field config scheme | Create per-project, configure card visibility per view |
| Board | Create board, configure columns, map to statuses | Board auto-generates from statuses |
| Estimated time | 2-4 hours + 1-3 meetings | ~10 minutes |
The right column isn't better because it's simpler. It's better when the complexity in the left column doesn't solve a real problem for your team.
Does a simple project management setup for developers scale?
This is the question people ask when they see a minimal setup. "Sure, it works for now. But what happens when the project grows?"
Here's what scaling looks like in practice:
More issue types. You realize you need a "Spike" type for research work. Add it in project settings. Takes 10 seconds.
More statuses. The team wants a "QA" stage between "In Review" and "Done." Add it. Existing issues stay where they are. For more on renaming and restructuring statuses, see how custom statuses shape your project workflow.
More views. You want a timeline for release planning. Create a timeline view, set date ranges on your issues, group by status or assignee. Same data, different perspective.
More fields. The team starts tracking "Feature Area" (Auth, Dashboard, API, Payments) to filter the board during planning meetings. Add a single-select field, done.
More people. New team members join. They open the board and understand the workflow in minutes. No training on schemes, no Jira admin onboarding.
The setup grows incrementally. You add what you need when you need it. No upfront architecture decisions that lock you into a structure you might outgrow.
What about teams already using Jira?
If your team is on Jira and it's working, stay on Jira. Switching tools has a cost and if the current setup isn't causing friction, the move isn't worth it.
But if you're starting a new project, setting up a new team or feeling the weight of configuration overhead every time something needs to change, it's worth trying a different approach. You can run Eigenfocus alongside Jira for a single project and see if the lighter setup works for your team.
Eigenfocus is self-hosted by default. Deploy it with Docker, and your data stays in a local SQLite database. There's also a cloud option if you'd rather not manage infrastructure. Either way, there's no per-user pricing. Your costs don't change as the team grows.
Frequently asked questions
Can I use Eigenfocus for a simple project management setup without Jira?
Yes. Eigenfocus is designed for teams that want project management without enterprise configuration overhead. Create a project, define your issue types and statuses, add custom fields and start working. The whole setup takes minutes, not meetings.
Do I need an admin to manage Eigenfocus?
No. Project settings like issue types, statuses, custom fields and views are managed by project members with the right role. There's no global admin panel for schemes or configurations. Each project manages its own setup independently.
How does Eigenfocus handle workflow transitions?
Eigenfocus doesn't enforce transitions. An issue can move from any status to any other status. This keeps things flexible for development teams where work doesn't always follow a linear path. A bug might go from "In Progress" back to "Backlog" or from "In Review" directly to "Done."
Is Eigenfocus only for software development teams?
No. The issue types, statuses and custom fields are fully configurable per project. Development teams use types like Bug, Feature and Task. A marketing team might use Campaign, Content and Review. The structure adapts to whatever work you're tracking. See how teams use Eigenfocus for software development and other workflows.
Can I self-host Eigenfocus?
Yes. Eigenfocus runs on Docker with SQLite. One container, one database file. Self-hosting is the primary deployment model. The source code for the Free edition is publicly available on GitHub (source-available). There's also a cloud option for teams that prefer managed hosting.
What does Eigenfocus cost compared to Jira?
Jira Standard starts at $900/year for 1-10 users, billed annually. Add Atlassian Guard for SSO (~$4/user/month) and a time tracking plugin ($3-10/user/month) and costs climb quickly. Eigenfocus Pro is a one-time payment of $489 for self-hosted with unlimited users. The cloud option uses flat monthly tiers starting at $15/month. No per-user fees in either case.
Start with what you need
The best project setup is the one your team actually uses. If five statuses, three issue types and two custom fields cover your workflow, that's not a limitation. That's clarity.
Explore how teams use Eigenfocus for software development or as a project management tool.
Read more about setting up a project workflow from scratch or learn how custom statuses shape your project workflow. If you plan releases without sprints, see release planning for teams that don't do Scrum. For a structured approach to handling bugs, check out a simple bug triage workflow for dev teams.