The code is well organized, and as there's relatively little of it, it will be relatively easy for the author to change the code. As he starts to add features and accept pull requests, he will have to manually check via static analysis and manual testing to ensure that the code will still work perfectly.
As the code base grows, doing it this way reliably will become more difficult, to the point that he will begin to fear change.
There is simply no debate that a well tested code base is easier to confidently add features to, confidently refactor and debug than code with no tests at all. This is particularly true if you bring on new contributors who have had no experience with the codebase.
Humans are not computers, they are never as good at repeatedly executing all possible execution paths of an application without growing tired or over confident that it doesn't need to check some path because it's sure it works.
I would take a well tested codebase over a well organized one with no tests any day of the week, because I know I could confidently reorganize the code without breaking anything. (well tested does imply that the tests themselves are well organized, though).
The OP was asking for criticism. He should add tests, lots of 'em.