[perrygeo]

Two thoughts here. First, you say you're not done and don't have functioning software yet. Sounds like you've built many of the components in isolation? A bottom-up approach can work if you know exactly how they'll fit together (either through experience or part of a well-known framework or design pattern) but it sounds like you need a top-down approach here: Build the public interface and a test harness for it first. Then fill in the scaffolding until it meets your objectives, ie commit to working software from day 1 no matter how clunky. Top-down and bottom-up approaches aren't mutually exclusive, as long as they meet in the middle somewhere.

The second issue is more of a process one. Ask why do you hate adding points to tickets as though a ticket should be set in stone? Why do you avoid updating them? It sounds like your ticket system is providing unnecessary friction for you. This is fairly common in greenfield projects - there are so many microdecisions to be made on a minute-by-minute basis that capturing them all in tickets would be insane. Ticket systems are designed for a steady flow of bug/feature reports on existing software. So while it's nice to have the chaotic freedom of a greenfield scenario, it's usually worth it to get to "stable" quickly so you can treat it like a standard iterative project. But in that pre-stability time when the problem is still coalescing in your mind, it's a bit foolish to try and capture every microdecision in a ticket up front. You still need to capture it somewhere but it's more important to write coherent design documentation than individual tickets at this point.