How we handle custom requirements

At tchop.io, we understand that every business, every app, every community is unique—and sometimes our standard platform needs a little something extra to fully meet your goals. That’s where custom requirements come into play.

What are custom requirements?

Custom requirements are special feature requests or unique implementations that go beyond the standard functionality of the tchop.io platform. These requests often come from clients who need tailored solutions to support specific workflows, branding needs, integrations, or business logic.

These could range from:

• New types of integrations or data feeds

• Unique design/UI customizations

• Feature enhancements or modifications

• API extensions or webhooks for special workflows

While we’ve built tchop.io to be flexible and powerful out of the box, we know that sometimes, unique needs arise—and we’re always happy to explore them with you.

How we manage custom requests

When a custom request comes in, it doesn’t go into a black box. We have a clear internal process to ensure every request is discussed, reviewed, and evaluated carefully.

Here’s a look behind the curtain:

1. Initial review
   Our team reviews the request to understand the what and why behind it. We might ask follow-up questions to clarify goals or suggest alternative solutions.
   
   

2. Internal discussion
   The request is discussed with product, design, and engineering teams. We assess its alignment with our product roadmap and its potential value for other customers.
   
   

3. Evaluation across three axes
   We evaluate each request across three key axes:
   
   

   • Value to the client and community
     Does the feature solve a critical need? Could it benefit other clients as well?
     
     

   • Strategic fit
     Does it align with where tchop.io is heading as a platform? Will it complement our existing features and long-term vision?
     
     

   • Technical complexity
     This is a crucial one. We assess:

     • Will this create technical debt or future maintenance headaches?

     • Could it introduce bugs or instability in other areas?

     • Does it require extensive changes to core infrastructure?

     • How hard will it be to test, support, and document?
       
       

   This third axis helps us understand the long-term cost of implementing a feature—not just building it, but maintaining it over time.

What happens next?

Depending on our evaluation, we may:

• Approve the request and provide a timeline for implementation

• Offer an alternative solution using existing features

• Add it to our feature backlog for potential future development

• Decline it if it poses significant technical or strategic challenges

If you urgently require a certain feature and don't want to wait until we can start implementation, there is also the way for paid custom work. In these cases we come up with a transparent proposal, what also puts our above analysis into consideration.

We believe in transparent communication. If a request isn’t feasible right now, we’ll explain why—and we’re always open to revisiting ideas as our platform evolves.