
ACTIQO
The activity lasts an hour. The coordination lasts all week.
Instead, I pushed it to August 30.
Not because the product isn’t real. ACTIQO is built, approved by Apple, and working.
But every final walkthrough keeps exposing something else I want to fix.
And I’m realizing this might be one of the hardest parts of building a product:
Knowing the difference between “not ready” and “not perfect.”
There will always be another edge case.
Another UX improvement.
Another screen I could polish.
Another flow that could be cleaner.
Another feature I wish was further along.
But at some point, continuing to build becomes a way of avoiding the question that actually matters:
Will people use it?
So I’m giving myself two more weeks.
The goal isn’t to make ACTIQO perfect by August 30.
It’s to make the core experience trustworthy enough that real families can use it, then let their behavior tell me what deserves to be built next.
For founders who’ve been here:
What did you intentionally leave unfinished when you finally launched?
That sentence took a lot longer to write than I expected.
The build itself was only part of the challenge.
There were rejected submissions, subscription issues, Sign in with Apple problems, TestFlight builds that behaved differently than expected, and several moments where fixing one thing seemed to break another.
At some point, App Store approval stopped feeling like a routine launch step and started feeling like its own product milestone.
But approval also changes the question.
For months, the question was:
“Can I get this working well enough to launch?”
Now it becomes:
“Will families actually use it?”
That part is more exciting, and honestly, more uncomfortable.
ACTIQO helps families manage everything surrounding kids’ activities, including responsibilities, reminders, preparation, handoffs, and the invisible coordination burden that tends to live in one parent’s head.
The activity lasts an hour.
The coordination lasts all week.
Getting through Apple’s review process was difficult, but it was still something I could control through persistence and problem-solving.
User adoption is different.
Now the product has to prove that it deserves a place in someone’s life.
For founders who have made it through a long launch process:
Did approval feel like the finish line, or did it immediately make the real work feel more real?
1 Like
Comment
Because then the questions change.
Early on:
“Can I build this?”
Eventually:
“Should I build this?”
I’ve spent months building ACTIQO, testing flows, fixing bugs, improving onboarding, and refining the problem.
The hardest part hasn’t been adding features.
It’s knowing when to stop.
There is always another improvement:
cleaner UX
better onboarding
another edge case
another feature idea
another thing you know could be better
But eventually the only thing that answers the biggest question is real usage.
Do families come back?
Does this become a habit?
Does it solve a problem painful enough that people make room for it?
That’s the uncomfortable transition I’m working through now.
Moving from building the product to letting the product prove itself.
For other founders:
How did you know it was time to stop polishing and start pushing for users?
1 Like
Comment
Lately I’ve realized the obvious problem is usually just the symptom.
For ACTIQO, I thought the problem was helping parents decide which kids’ activities were worth their time and money.
After talking to parents and rebuilding the product, I realized the bigger problem shows up every day.
It’s remembering who has practice.
Who’s driving.
What’s packed.
What changed.
Who’s responsible.
The activity lasts an hour.
The coordination lasts all week.
That shift completely changed what I’m building.
I’m curious, what’s the biggest assumption you’ve changed about your product after getting closer to your users?
1 Like
Comment
It’s knowing when to stop doing everything yourself.
As a solo founder, every dollar matters.
So the default answer is usually:
“I’ll just figure it out.”
Need better UX?
Learn UX.
Need marketing?
Learn marketing.
Need design?
Watch YouTube.
Need QA?
Test it yourself.
Eventually, though, you hit a point where the real cost isn’t the money.
It’s the opportunity cost.
The hours spent learning something outside your expertise are hours you’re not spending improving the product or talking to users.
I’ve reached that point with UX.
I can keep iterating myself, or I can invest in someone who sees problems I’ll never notice because I’m too close to the product.
For founders who’ve crossed that line:
What was the first thing you decided was worth paying for instead of learning yourself?
And looking back, was it the right decision?
1 Like
Comment
Then I watched 13 parents go through usability testing.
The surprising part?
Most of them described the exact problem I built ACTIQO to solve.
Not scheduling.
Not calendars.
Not tracking.
Coordination.
Things like:
• remembering who has pickup
• making sure equipment is packed
• coordinating schedule changes
• figuring out when to leave
• communicating across multiple adults
• keeping everything in their head
One parent basically described family life as logistics management.
That changed how I’m thinking about the product.
Instead of positioning ACTIQO as a family activity tracker, we’re leaning much harder into a different idea:
“The activity lasts an hour. The coordination lasts all week.”
The UX still needs work.
But the testing made me realize something important:
The problem wasn’t that parents didn’t have the pain.
The problem was that I wasn’t making the value obvious enough.
Curious for other founders:
What’s the biggest thing user testing taught you that had nothing to do with UX?
1 Like
Comment
Every UX audit I’ve received has found real issues.
The problem is that every fix tends to uncover three more things to improve.
At some point you start asking:
Do I keep refining?
Or do I put the product in front of more users and see what actually matters?
Right now I’m building a family coordination platform and I’m at the stage where I could easily spend another month polishing onboarding, navigation, and edge cases.
But I’m increasingly convinced that watching 10 real users struggle is more valuable than reading another 20-page audit.
For founders who have been through this:
How do you decide when a product is “good enough” to stop optimizing and start learning from real usage?
1 Like
Comment
Not driving to practice.
Not attending games.
Not paying for activities.
The job is remembering.
Remembering:
who has practice
what time to leave
what needs to be packed
who’s responsible
schedule changes
pickups
uniforms
equipment
One activity is manageable.
Five activities across multiple kids becomes an operating system.
And most families are still running it manually in their heads.
The activity lasts an hour.
The coordination lasts all week.
What’s the biggest thing your family is constantly trying to remember?
1 Like
Comment
Originally, I thought I was building a product to help families make better decisions about kids’ activities.
Things like:
- Is this activity still worth it?
- Is my child enjoying this?
- Are we overscheduled?
But after talking to parents and watching how family schedules actually operate, I realized something deeper:
Most families are not overwhelmed by the activity itself.
They’re overwhelmed by the coordination surrounding it.
The practice lasts an hour.
The coordination lasts all week.
Who’s driving?
What time do we leave?
Do we have everything?
Who’s responsible tonight?
Did anyone communicate the schedule change?
Is the uniform clean?
Can grandma do pickup?
What happens if one child’s schedule changes?
Modern family life increasingly behaves like an operational system.
But most families are still running that system manually through:
- memory
- texts
- anticipation
- invisible labor
- constant mental tracking
That realization completely changed how I think about the product.
I originally thought the wedge was:
“decision intelligence”
Now I think the wedge is:
“coordination relief”
Not:
“help families think better”
But:
“help families coordinate better”
And weirdly, I think that emotional shift matters a lot.
Because people don’t build habits around reflection.
They build habits around relief.
Curious if anyone else building products has had a moment where the REAL problem turned out to be operational instead of conceptual.
1 Like
Comment
The real problem isn’t “too many kids activities.”
It’s that most families no longer have a clear sense of what “normal” even looks like anymore.
Practices, lessons, travel teams, enrichment, extra training… schedules gradually expand until constant movement starts feeling standard.
And because everyone around you is doing similar things, it becomes hard to tell the difference between:
- healthy engagement
- and chronic overload
What’s been interesting building in this space is realizing parents aren’t necessarily looking for more optimization.
A lot of them are looking for clarity.
Questions like:
- Does this schedule still feel sustainable?
- Is this creating energy or draining it?
- Is my child actually enjoying this anymore?
- Do we still have room to breathe as a family?
That shift in framing changed how I think about the product entirely.
Less:
“activity management”
More:
“family decision intelligence”
Curious if anyone else building products has had a moment where the real problem turned out to be emotionally different than the original surface problem.
1 Like
Comment
About
I built ACTIQO because kids’ activities require far more than the activity itself. ACTIQO helps families coordinate the work and decide what remains worth their time, money, and energy.

Comment