Bassist

Idea to Product accelerator

Comment

🚀 Our Story

Across our careers in tech, one recurring pain kept surfacing-for developers, teammates, and project managers alike: managing tickets and boards.

On paper, ticket management sounds simple. In reality, once development goes full throttle, a gap quickly forms between the actual state of the project and the state reflected on boards.
This gap exists largely due to communication breakdowns:

  • PMs don’t always understand the real complexity of tasks.
  • Developers don’t always have enough context to estimate accurately or guide newcomers.
  • Tickets go stale, estimates drift, and boards stop reflecting reality.

Bassist exists to close that gap-using automation and LLMs to keep project state, tasks, and execution in sync.

💡 The Solution

Bassist allows you to define a project topic and then autonomously manages the workflow end-to-end:

  1. Documentation Generation
    Automatically creates structured project documentation from high-level input.

  2. Task Generation with Estimates
    Generates task lists with estimates derived from:

    • Past project data
    • Historical task patterns
    • General project context

  3. Multi-Platform Ticket Creation
    Syncs tasks directly to platforms like:

    • GitHub
    • GitLab
    • Jira
    • and more

  4. Agent-Driven Execution
    Tasks can be handed off to AI agents that:

    • Fix bugs
    • Implement features
    • Learn from open & closed tasks
      with human-in-the-loop when required.

  5. AI Actions
    Ask natural-language questions like:

    • "What’s blocking this sprint?"
    • "Why is this task delayed?"
    • "What changed since last week?"

📚 What We Learned

Prompt Engineering

One truth became obvious very quickly:

Garbage in, garbage out.

There is no shortcut to good prompts.
They must be explicit, intentional, and iteratively refined.

Structured Output from LLMs

LLMs are powerful-but unreliable without guardrails.

We learned to:

  • Use schema validation (e.g., zod)
  • Write stronger system prompts
  • Implement retry loops
  • Perform careful string parsing and sanitization

This significantly improved frontend reliability.

MCP - When to Use It (and When Not To)

We started with the wrong assumption-and learned the hard way.

Our initial goal was learning and experimentation. But once Bassist evolved into a user-facing product, reliability and predictability became non-negotiable.

This shift forced us to rethink:

  • Where MCP fits
  • Where deterministic systems are required
  • Why "AI replacing jobs" is still far from reality 😉

LLMs are incredible assistants-but not autonomous replacements.

🛠 How We Built Bassist

Bassist began as a CLI tool used internally for personal and work projects.

Typing commands repeatedly became tedious-so we added a UI.
That’s when Bassist started becoming a product.

Early versions:

  • Were heavily MCP-centric
  • Routed nearly every user action through MCP
  • Were slow, hard to debug, and unpredictable

Through iteration, we:

  • Converted the CLI into a server
  • Built a minimalistic UI
  • Re-architected the system to be customer-centric, not just an LLM wrapper

Thanks to:

  • Google’s excellent GenAI SDK documentation
  • Transparent pricing
  • Strong frontier-level Gemini models

Choosing Gemini as the core model was a no-brainer.

Challenges We Faced

Over-Reliance on MCP

We initially tried to use MCP for everything.

Problems:

  • Slow execution for basic tasks
  • Tool-selection errors
  • Difficult debugging
  • Unacceptable unpredictability for end users

Solution:

  • MCP was removed from the core execution path
  • Reintroduced as an extension platform via AI Actions

Result:

  • Massive performance improvement
  • More predictable behavior
  • Easier debugging and maintenance

We’ve built systems that can act autonomously-but they still have a long way to go.

Managing Multiple Integrations

Integrating platforms like GitHub was surprisingly complex:

  • Each platform behaves differently
  • Error handling varies wildly
  • Maintaining strict schemas for both LLMs and the database was painful

Refactoring these integrations from an MCP-centric design to a hybrid architecture tested our patience-but paid off.

Streaming & Parsing LLM Output

Streaming responses are inherently unpredictable.

Our core principle:

Errors are acceptable. Broken UI is not.

We ensured:

  • The UI never crashes
  • Failures are recoverable
  • Users always receive actionable feedback

Prompt Predictability

LLMs are probabilistic-not deterministic.

We stopped chasing "perfect predictability" and instead:

  • Upgraded model versions
  • Added validation layers
  • Implemented retry strategies

This dramatically increased the success rate of structured outputs.

🔮 Future Scope

  • AI-driven project analytics
    Examples:
    • "How many people do I need to ship this before monsoon?"
    • "Will this sprint finish on time? If not, why?"
  • Support for more LLM providers and model selection
  • Expanded integrations
  • Publishing deep-dives on real-world LLM usage
  • Sharing lessons learned while continuing to improve Bassist

We’re building Bassist not just as a product-but as a learning platform for better AI-assisted software development. We are alwasy looking for everyday problems to be solved and we are curious how we can contribute to the society with tech and LLMs integrated in to tech

Built With

Share this project:

Updates