beybol

I am a software engineer and security consultant.

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 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.

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.

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.

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?

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.

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.

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.