We Built Otper to Solve a Problem We Kept Seeing in Project Management

Building software teams rarely have a problem creating tasks.

There are plenty of tools for that.

Create a board. Add a task. Assign someone. Move it from To Do → In Progress → Done.

It works.

Until the team grows.

Then the problem changes.

You don't just need to know what is happening inside a project.

You also need to understand what each person owns across projects.

That's one of the problems that led us to build Otper, a project management workspace focused on ownership and delivery.

The problem with project-centric work management

Imagine a development organization with three teams:

• Product
• Engineering
• QA

Each team may work across multiple projects.

A developer could be contributing to Project A, Project B and an internal initiative at the same time.

Each project can have its own Kanban board.

From the project manager's perspective, this looks perfectly organized.

But now ask:

What work does this developer currently own across all three projects?

You may need to open multiple boards to find out.

The information isn't necessarily missing.

It's fragmented.

Boards organize projects. People organize responsibilities.

This distinction became important to us while designing Otper.

A board is great for understanding a project's workflow.

For example:

Backlog
   ↓
To Do
   ↓
In Progress
   ↓
Review
   ↓
Done

But a person doesn't necessarily work on one board.

Their actual work might look more like:

Developer
│
├── Project A
│   ├── API integration
│   └── Bug fixes
│
├── Project B
│   ├── Authentication
│   └── Database migration
│
└── Internal
    └── Technical documentation

The project view answers:

"What is happening in this project?"

The ownership view answers:

"What is this person responsible for?"

We wanted both views to exist within the same workspace.

The structure we used

Otper uses a relatively simple hierarchy:

Company
   ↓
Team
   ↓
Board
   ↓
Task

The simplicity is intentional.

Teams can organize work into boards without losing the relationship between tasks and the people responsible for them.

This also gives us a foundation for looking at work from different perspectives.

Project perspective

You can look at a board and understand:

• Current tasks
• Task status
• Project progress
• Pending work
• Delivery activity

Ownership perspective

You can instead start with a person and ask:

• What tasks do they own?
• Which projects are they contributing to?
• What work is still pending?
• What has been completed?
• How is their workload changing?

The second perspective is particularly useful when people work across multiple teams or projects.

Why we didn't want reporting to be a separate activity

One thing we wanted to avoid was making reporting another manual process.

In many teams, project tracking and reporting can become separate activities.

Developers update tasks.

Project managers collect information.

Managers ask for status updates.

Someone eventually creates a report.

We think there is a better approach:

Work
 ↓
Task updates
 ↓
Ownership
 ↓
Progress
 ↓
Reporting

The information generated while doing the work should also help explain the work.

That doesn't eliminate every reporting requirement, but it can reduce the amount of manual reconstruction needed to understand delivery.

Building a SaaS product around a simple idea

From an engineering perspective, the interesting part wasn't simply creating another Kanban interface.

The harder question was:

How do you keep ownership meaningful when the same person participates in multiple workflows?

That affects the way you think about:

• Data relationships
• Permissions
• Team structures
• Task queries
• Reporting
• Activity tracking
• User-level aggregation
• Project-level aggregation

A task isn't just a card on a board.

It is part of a larger relationship:

Company
   │
   ├── Team
   │     │
   │     ├── Board
   │     │     │
   │     │     └── Task
   │     │            │
   │     │            └── Owner
   │     │
   │     └── Board
   │
   └── Team

Once you start looking at the data this way, reporting becomes less about generating another document and more about querying the underlying work model.

What we're trying to build with Otper

Our goal isn't to replace every project management workflow.

Different teams work differently.

Some teams need detailed Agile workflows. Others need straightforward Kanban boards. Some need roadmaps and delivery reporting.

What we're exploring with Otper is a common layer across these workflows:

Ownership + Work + Progress + Delivery

The idea is simple:

If you know what work exists, who owns it, where it belongs and how it is progressing, you should be able to derive useful operational visibility from that information.

We're still building

Otper is a new product from Sword Software N Technologies Pvt. Ltd. (SSNTPL), and we're continuing to develop it based on how teams actually use the product.

We're particularly interested in feedback around:

• Cross-project task visibility
• Team workload
• Ownership reporting
• Kanban workflows
• Roadmaps
• Delivery tracking
• SaaS integrations

If you're building a software team or managing multiple projects, we'd be interested in hearing how you currently solve these problems.

You can explore Otper at https://otper.com/.

For a deeper look at the ownership model, we've also documented the concept here:

Task Ownership in Otper: https://otper.com/task-ownership/

---

Otper is built by SSNTPL, a software development company working across custom software, SaaS, AI/ML and other technology solutions.