My product is a time tracker with many options I use to bill my clients like timer, manual entries, rounding, prepaid hours. I created my own tool to meet my requirements and I want to share with others. There is no paid plan and there never will be. I earn from my services, not from this project.
This project is spec-driven with strong focus on data privacy and security.
There are 89 ADRs, 120+ tasks implemented, 254 commits covered by unit, functional, mutation tests and security reviews. Everything hosted in GCP/Europe (europe-west1). Platform: PHP 8.4/Laravel 13.8/Filament 5.
It is easy to test it, one can log in by email (requires email confirmation) or Google authentication. If you don't like it there is an option to delete the account with all the data after 30 days (before one can restore the account).
Feel free to test, use it, challenge, ask questions or comment.
I have scanned logs of my 5 small projects, one medium financial platform and one large e-commerce site. I was searching for memory anomalies and unusual POST sizes. I also checked if new files were created, IAM logs and reviewed in the database new accounts with high privileges. There is no indication in the logs that someone tried to exploit my services.
The purpose of code review is to check if the PR implements what was meant to be implemented. The code should be verified against task specification and ADRs, plus some technical checks like comments, test coverage, semantics.
Not everything may be found in code review and tests. I recommend also mutation tests. In one of my projects mutation tests discovered a real problem in the code.
In server logs you can distinguish the type of LLM's traffic. OAI-SearchBot/GPTBot/ClaudeBot is just indexing but ChatGPT-User/Claude-User etc. may be valuable traffic generated by user's conversation with LLM's. So it's worth choosing which ones you block, instead of blocking all of them.
What's the value for the website maker in these? There's user value to it (rather than just value for Anthropic/OpenAI) but the whole point of these bots is to make sure nobody ever needs to visit your website.
Tons of people click from ChatGPT! It's now the top referrer on most of my websites, and seems to be on path to overcoming Google soon (a ton of traffic from Google has vanished since the AI Overview rollout...).
I realized its much faster to do the "google thing" just with chatgpt. Its filters all the sh!t for you. Searching the net frustrates me most of the times this days. Search engines are software for an older generation of the www.
In my case this is the main source of registered users. If a user is engaged in a discussion with chatbot and gets the recommendation from it his engagement is higher. For example, in my system, a user has registered and within one hour used the system 7 times and stayed active while for registrations from Google I can observe zero-activity accounts.
Strong agree, a good way forward is letting user agent once again truly mean an agent on behalf of the user. And speaking anecdotally, I've seen different traffic "shapes" under the same UA, which leads me to suspect that some actors might be disguising traffic as more mainstream labs.
Cheap development is not equal to cheap maintenance. It is easy to generate the code but verification, acceptance criteria, documentation and maintenance are the real cost.
There is a solution for green test suite - mutation tests. Testing your tests gives you solid ground to treat green tests as reliable. It takes time but also brings quality.
In terms of an agent reporting green tests never executed, a proper step in deployment workflow may be a good gate.
A problem often arises when a paid plan competes with a free one within the same product.
Clockify limited basic functions (data export, billable rates) in April to convert users from free to a paid plan. Google has now moved free competitive models behind paid plan as well. It happens all the time - nothing unexpected. Clockify, Gemini are just examples.
In my projects WHY always goes to ADR because every decision should be well documented, not only as a comment but with arguments. Moreover a decision may change and the change should be documented too. A published commit message is unchangeable. In one of my projects I have 170 commits and 85 ADRs where one is accepted temporary and one superseded by another.
For me, social media and directories (like SaaSHub, Capterra etc.) are not working. Of course, you should try them and track the results — measure the traffic generated by each source. Be aware that logs may rotate, so make sure to check them frequently, save and analyse.
In my case, the only source of traffic and registrations is recommendations from AI assistants, so I focus on GEO - structured data in the source, proper indexing in Bing and Google.
I am running a small-scale project without a marketing budget, so this is more of an observation than a conclusion based on proven, repeatable statistics.
By structured data, I mean a JSON-LD section in the source code that describes my project. I've included: WebApplication, offers.price: 0 , sameAs, FAQPage. Bing read it but still I don't have a proof how effectively it influences LLM-s.
So far directories didn't bring me registrations but my scale is too small to determine whether being listed in directories helps with user acquisition or SEO/GEO while I observe registration with LLMs refer.
How do I measure that? I correlate server logs with application log (mainly registrations). I observe for example GPT scans as a result of conversation with user and seconds/minutes after that entry and registration in the system. It supprts my observation about traffic source quite accurately.
Can you provide more data here and let us know whether LLMs regularly scan directories and how it looks on your end?
I don't rely on time calculations at the database level. I handle them in the application based on UTC time stored in the database and the user's time zone. This shifts the problem to the application code, where I can control it precisely and make conscious decisions about how to handle specific business requirements, such as when a day ends or how to deal with events across different time zones. It also makes it possible to properly test all cases with unit tests.
I've seen too many ways storing everything as UTC goes wrong/gets confusing. Round-tripping at least UTC offset (which unfortunately Postgres `timestamptz` in this case does not do and is effectively the same as storing as UTC) gives you more debugging tools for events in the past and more opportunities to do the right thing for future events in worst cases (strange, unexpected DST shifts). The best option is if you can also round trip exact time zones such as IANA strings like "America/Los_Angeles". Even fewer databases support that natively right now (as a single optimized column).
When UTC offsets roundtrip you can do all your date math as if everything was in UTC, but still not lose information from the user about what time they thought an event occurred at or might next occur at.
t depends on the system. Keeping a time zone alongside a UTC timestamp may be useful in some cases.
For example, if your system is supposed to remind a user to do something, such as take a pill, and the user changes time zones while travelling, you may want the reminder to occur at 9:00 local time wherever they currently are. In that case, storing the original time zone together with the event may not be necessary, because the relevant time zone is the user's current one.
Everything depends on the context. For me, however, there is no doubt about one thing: I store timestamps in UTC. Whether I also store a time zone, and where I store it, depends on the system and its business requirements.
Keeping a UTC offset is two extra bytes and with a UTC offset you can do all of your time comparisons and time math as if everything was in UTC, but you have extra debugging information in the UTC offset. It's still sometimes useful to store a time zone as offsets to timezones certainly are not 1:1 (esp. with DST math), but some places like logs and past dates UTC offset is sufficient and you don't even need to store timezone.
Postgres doesn't a native type that supports UTC offsets, but some other databases do and it is extremely useful. At this point in my career, I would never choose UTC storage over UTC Offset storage.
We can think of the split between DB and application in terms of DX or code, or we can think of it in terms of colocation of data and compute. The latter case will be compelling sometimes.
This is the only way. To do otherwise smacks of poor programming practice and is very often a sign the coder doesn't habitually consider the world outside their own timezone.
It only works backwards (though you can probably get away with it if your future dates are not too far forward). There are ~10 tzdb updates a year due to rule changes and if you bake a date on the other side of one to UTC too early then your app is going to have incorrect datetimes
Ruby on Rails would agree with you. I've been working in web development for a decade now, across a couple of languages and frameworks, and I've only ever stored UTC. I currently work a lot with time-series data, and I'd rather not know what hack makes it possible to track events that occur during a DST transition.
I don't know the exact use case, but it sounds weird. If UTC is the single source of truth, then when you display the data and want to change some business assumptions, you only need to change the application logic. The underlying data remains unchanged.
One scenario I can imagine is when you want to store the results of business calculations in the database. In that case, once the algorithm changes, you may also need to update the stored data. This may be necessary for performance reasons.
In all other cases, calculating the result on the fly solves the problem and does not require a database update when the business rules change.
I suspect they meant more generally “the date&time field”, but a store in Boston that opens at 7:30 AM and closes at 7:30 PM Eastern time (ET) closes on different UTC date than it opens when ET is EST but opens and closes on the same date when ET is EDT, so it’s plausible that the dates actually needed to be updated.
My product is a time tracker with many options I use to bill my clients like timer, manual entries, rounding, prepaid hours. I created my own tool to meet my requirements and I want to share with others. There is no paid plan and there never will be. I earn from my services, not from this project.
This project is spec-driven with strong focus on data privacy and security. There are 89 ADRs, 120+ tasks implemented, 254 commits covered by unit, functional, mutation tests and security reviews. Everything hosted in GCP/Europe (europe-west1). Platform: PHP 8.4/Laravel 13.8/Filament 5.
It is easy to test it, one can log in by email (requires email confirmation) or Google authentication. If you don't like it there is an option to delete the account with all the data after 30 days (before one can restore the account).
Feel free to test, use it, challenge, ask questions or comment.
reply