this is my journey through buildspace s5. i'm going to use the same lowercase everything format that buildspace uses to match the theme. in terms of reasoning i'm not sure what the lore is yet. i will ask farza if i meet him at some point.

week 0

heard from a friend that buildspace s5 is happening and got a buddy pass invitation. spent the whole week thinking about what to work on but nothing too interesting came up. on saturday after watching the kickoff with fellow builders at soto, an attendee was looking to get food since they came all the way from waterloo. he went around and asked around for food recommendations, some suggested a bunch of places and some said they don't know and by the end he didn't seem set on a place to go either. that feeling of being overwhelmed was too familiar since i struggle with the same choice overload when looking for places to go as well. while the words of farza telling everyone to "build something that they themselves will use" was fresh in my head, i decided to try and do something about this choice overload or more formally known as decision fatigue. i'm not a psychiatrist or some kind of human behaviour expert, but i do know how to code and create software that helps with everyday problems. so, time to update the apple notes:

week 1

i was attending collision this week so i didn't have much time to think and explore other ideas. i didn't even get to watch the first lecture. so when it was time to lock in an idea and create a intro poster for it i went with the idea that would be the most help to myself. the task of this week was to create the intro poster and share it on social media to get feedback on your idea. this is what i ended up with:

llms can be very random because end of the day they're just highest probability sentence generators. i'm planning to take advantage of that to help myself with decision fatigue and hopefully others will find it useful as well. s5 submission@_buildspace @_nightsweekends @farzatv pic.twitter.com/lkarz1bfov

— arian (@thearian81) june 20, 2024

while creating the poster i decided that the name "just1" looks cooler than "just one" so that's the name i chose. suddenly i realized i will also need a domain and in a rare strike of genius i snatched the domain just1.place for a whopping $24. i didn't have much to put there so i just took the poster i had and remade it in react so it can be the landing page while i cook the main project.

i haven't really discussed concretely what just1 is going to be so here's a brief description of what i've planned the project to be so far,

now i don't know how much of this i can do for buildspace but the main goal is to have a usable product that can suggest only one option so you don't have to make a choice, the ai made the choice for you.

that's it for first week. i'm gonna start coding an mvp next week.

week 2

i was really busy with personal life this week, to the point of just collapsing on bed and sleeping when i got home every night. on the weekend, i went on a camping trip where i had very limited, slow internet. i couldn't do much as far as developing the project goes, but i realized my project's first pitfall:

this issue left me with 3 options:

1. give up on feeding the model with a lot of reviews and just rely on the few reviews provided by the api. this is the easiest solution, but it will affect the output quality drastically.
2. use a third-party api like serper api to get access to all reviews. this would be amazing as, in terms of complexity, it's as easy as using the google official api, but the problem is that this api is extremely expensive. i would be burning through $70 before even finishing development.
3. write my own scraper to get the reviews from google's private apis used on google maps. this solution would give me access to the data for free, but writing a scraper is more complicated than using an official api, and it's against google's terms of service!

i spent most of my weekend thinking about which approach to go with before doing much coding because this is crucial in the process of making this app.

i ended up going with the first approach while developing the app and upgrading to a better method when the rest of the app is fully developed. however, while evaluating those solutions and thinking about the app architecture, i came up with an ingenious (if i say so myself) method of calling the api. it relies on how the api calls are made to the maps api.

following is the json sent to the api to get nearby places:

{
   "includedtypes":[
      "ice_cream_shop", "restaurant"
   ],
   "maxresultcount":10,
   "locationrestriction":{
      "circle":{
         "center":{
            "latitude":[latitude],
            "longitude":[longitude]
         },
         "radius":5000.0
      }
   }
}

most of the values are hardcoded. the result count would stay the same when settling for a value that gives the best results through trial and error, and location data comes from the browser's geolocation data. the radius is also a constant value which would be reasonable for a walkable destination. there will be an option for the user to increase the radius if no results have been returned by the model. the part of the body that's most important and needs to be dynamic based on the user query is the includedtypes. this parameter decides what types of locations to be returned by google's api. this is a perfect use case for an llm to run categorization on the query by the user to figure out what kind of location types should be included.