Super interesting work! Maybe one day you will also be able to have a career as a science fiction writer. Lot of interesting outcomes can come of this. ❤️

It's still a bit early days. For nocturnal flight calls (which are the majority of the mysteries) the recordings are generally of poor quality and the model doesn't find anything (according to the tresholds we have set). We are running the model in the background on focal recordings from Europe as well, and there performance is pretty good. As we are not runnign BirdNET alongside AvesEcho, I cannot say at this stage which one is better, but my expectation is that AvesEcho should be an improvement, as it is based on BirdNET and is then further trained with more focal recordings. But time will tell if that is indeed the case!

This looks awesome!

It's a really good question, Colleen!

Ideally, I would work with two developers, or at least one developer and one other party who knows what developing an app like this would mean. This will lower the risk that the developer answers your question too much in their advantage. So this is one reason why it is a good question, and maybe this is why you ask it. However, if you really trust your developer not to take advantage, then go with just her/him/they.

It's also a good question because there is no easiest way to go about this if you're on a budget. You mention that you do not have a tech background, so here comes some explaining. If I misunderstood, then please skip and continue at "Back to 'the easiest way to go about this'"

There are at least two things you should be really aware of when it comes to software development.

The first is that once the basic data structure is defined and the software built around it, it is extremely costly to change the data structure. It's like deciding after the car has been built, that the engine should go to the back of the car instead of the front.

The second thing is that the basic data structure is dependent on ( among other things, but I'd say these are the two most important factors ) the complexity of what needs to be achieved and the speed at which it needs to be done.

The difficulty is that the required complexity and the speed may change over time, which brings one back to the car and engine situation. Changes in complexity and speed requirements may be the result of many things, one of which is success. You get far more clients than anticipated, so the system needs to be scaled up. In addition, with more users come more feature requests ( this can work both ways: new features result in more users, and more users may result in more feature requests ).

There is no real solution to this problem ( well, except not growing beyond the point that the first design can handle ). When it comes to scaling up, one vendor may claim that their database back bone easily scales up. Maybe so - but it may come at a price and they may also underestimate your and their own future needs. When it comes to changes in complexity, additional features can in the beginning probably be added on without changing the basic data structure. Maybe an additional row of seats at the back of the car, a trailer hook, bigger lamps, a roof-rack, a trailer, suitcases on the rack. At some point the car will need a new and bigger engine to carry all those add ons and keep at the same speed.

Here is a prediction : the more you stress cheap and efficient at the beginning, the bigger these problems will be later on. But when the business is successful, there will be more money to invest in scaling up and redesigning. Obviously yes, but in terms of the car metaphor, you may find that you want the car to be kept running with all its added on features, while the engine is replaced and moved to the back. It may be possible, but perhaps out of reach of patience and the increased income.

Back to 'the easiest way to go about this':

Invest a little effort to find out not only what are the minimum requirements for the MVP, but also what else you or your clients may want in the future. The developer should then have these future requirements in mind (and future upscaling) when they start developing for the minimum ones. This means, develop a somewhat more generic data structure than what is necessary for the MVP. This will cost some more at the beginning but should save a lot later on. I'm writing 'should' not 'will' on purpose. It's a balancing act because taking too much into account has the risk of over-engineering for a future that may not happen, or develop differently than expected. Like I said, there is no easiest way out.

A few more detailed comments

If there is no API for a source, try to go around it if possible at the beginning. API's are made with some long term stability in mind. Websites and web pages not necessarily so or less so. They will require more monitoring and maintenance on the web scraping routines.

Perhaps the developer may not be aware of the necessary pre-work that needs to be done if the pre-work depends on biological knowledge needed to transform the data from your data sources into data that allows easy ( and fast ) calculation of results to the users.