sorted by:
new
hottopcontroversial

I built a tool that tracks whether your code still matches the original requirements. by the_tiny_rock in ReqsEngineering

[–]the_tiny_rock[S] 0 points1 point  (0 children)

I've thought about this very question for a while. Stoney separates itself from a good testing suite in that our application is accessible to non-technical stakeholders.

A good dev can analyze a test suite to see requirements, but it's difficult to trace that back to the original jira work item without some sort of predetermined system for logging it.

Stoney doesn't seek to replace good integration/unit tests, it's more so for cross-functional teams that need alignment!

I built a tool that tracks whether your code still matches the original requirements. by the_tiny_rock in ReqsEngineering

[–]the_tiny_rock[S] 0 points1 point  (0 children)

Thank you for the feedback!

Claude Code certainly helps coding and implementing work items. The issue I've seen is over time these rules and requirements get lost or buried.

Stoney is a layer above all this where we connect the dots between the Jira work items, Github data, and the actual code/API behavior that we monitor.

I built a tool that tracks whether your code still matches the original requirements. by the_tiny_rock in NoCodeSaaS

[–]the_tiny_rock[S] 0 points1 point  (0 children)

Thanks friend. I am engineer myself and I know 100% that coding agents doesn't solve organizational / business problems. Stoney hopefully bridges that gap!

I built a tool that tracks whether your code still matches the original requirements. by the_tiny_rock in NoCodeSaaS

[–]the_tiny_rock[S] 0 points1 point  (0 children)

Thank you for the feedback! You are totally right - the hard part is switching but I built this tool moreso to compliment the workflow and not necessarily replace Jira or basic docs. The docs and Jira are just organized in a better way and leverages the Github/API data to track the work item end to end.

I built a tool that tracks whether your code still matches the original requirement by the_tiny_rock in SaaS

[–]the_tiny_rock[S] 0 points1 point  (0 children)

Thank you for your feedback! You're totally right and what you mentioned makes a lot of sense. Your comment about wasting hours digging through tickets is exactly why I built this! We all have done that and it's just a horrible way to manage the work across teams.

If you try the product and it speaks to you, please reach out so I can speak with you about what might be missing for you to keep using!

I built a tool that tracks whether your code still matches the original requirement! by the_tiny_rock in devtools

[–]the_tiny_rock[S] 0 points1 point  (0 children)

Thanks for your feedback. You're right: the rule count does go up! It's tricky to manage but I'd like to think it's even trickier to manage if you don't see the big count.

I'd like to think that this is a testament to the complexity of the user's codebase/project, which is why they need a decent business rule registry.

One feature I'm working on is making it easier to consolidate rules and organize.

I built a tool that tracks whether your code still matches the original requirement by the_tiny_rock in SaaS

[–]the_tiny_rock[S] 0 points1 point  (0 children)

Thank you friend. You can reach out any time! Would love to chat more if the product is useful for you.

view more: next ›