>Several users have tried. None have succeeded.
But then
>What browsers does Kiki support?
>KIKI supports Chrome and Safari. Other browsers can confuse it. Stick to those two.
> Will KIKI judge me for my poor time management?
> Yes. That's part of why it works.
It's frustrating to me how often sales pitches try to obscure or dance around the nature of money in a fashion similar to your argument - thinking of so many alternate explanations for why something has a high pricetag or a recurring payment tied to it while profusely ignoring the "we want as much money as possible and we think this is the most you'll give us" reason. As if these businesses are our friends or something.
Sure, diming $30/year is a 'better deal' than nickeling $5/month, but this is not the sort of 'deal' which this software warrants. This is not a service product, and pricing it like one is silly.
that's what I usually do. :)
Same functions, costs less than one year of Kiki for life, and multiplatform. No AI required.
Putting the ones on the user to manage this is just adding one additional thing that requires executive function.
They could certainly put it in the FAQ, which is below the ([Apple Logo] Get the App) button, I don't actually disagree with you, but it is somewhat of a funny complaint to me given the actual content of the page.
It takes the same amount of effort to setup a recurring subscription stack vs a one off payment.
I might pay $5 to find out if your app is even useful. I will not pay $5 recurring monthly for an app I forgot existed until I notice it on a monthly credit card bill sometime in the future.
What I want is a one month subscription. I’ll sign up for recurring if I want to but it would require explicit action.
But nobody wants to offer that so they don’t get me at all. I assume there are others like me, perhaps even dozens of us.
the more I see that - the less I trust
(X) Doubt
It seems like there are three hard things in computer science: cache invalidation, naming things, and forbidding things.
Otherwise, why would anyone fill in the task description? That's just extra work for zero benefit (surely you know what you were working on?)
If I have to download a brand-new browser just to use this app, what's stopping me from switching back to Firefox to evade the blocks?
prodtodolist.com if you’re interested
> We need to eat. You need to finish things. That's capitalism, baby. Also, you value things you pay for (unlike those 17 free apps you downloaded and never opened).
Huh, I think I just found some new copy text for the SAAS I'm building!
It should not be very hard to write though, given that processes have predictable names, and executables have predictable signatures. Replacing the executable until the next time slot comes would additionally help.
Deploy a rootkit to make certain that the user cannot get rid of this software.
It might be easier and cheaper to have a dedicated device for that special thing, kept under a lock and key. Maybe the very insanity of such a setup would help reason overcome the addiction.
As a trivial application of the spec, consider that there are time-limitted trials of software. Once it's run for 30m, it'll never run again without significant intervention.
If you're the kind of person that's willing to go out of your way to invalidate the control spec rather than just abide by your own time control rules, you've got a more significant problem than you're willing to admit.
We don't need software that prevents running for 31 minutes in every 24 hour period, we need humans who are both willing and able to manage their time.
I mean, can you imagine being the kind of person that blames a piece of software for one's inability to stop using said software. Like it's somehow tiktok or youtube or android or linux or who the fuck ever's fault that you can't stop doomscrolling or gaming or gambling or whatever.
As a matter of fact, every software already supports what you're asking for. Run a script that monitors focus time and kills after a certain period if you're really so unable to simply close the software based on your own paradigm. Leave the script running and have it issue kills for the entire duration of your specification. [use=focustime/24h; while use>30m/24h, kill proc.exe].
There are already existing implementations of this that, for instance, limit a user acct to a certain amount of time per period. Imagine a library that only allows 30m/account. I just got out of an environment that only allows accts to access for a maxiumum of 15m with one sign on with a 15m cooldown. If you used it for 3 minutes and signed out, you'd have to get back in line for 15m. If you demanded using it as much as possible you would use it for 15 and wait for 15.