Inspiration for the project

WasteWise grew out of real-world needs based on feedback from potential customers.

The process

I begin most Bolt projects by identifying and describing the main app features. Once I'm satisfied with that list, I will make a first pass at the needed db tables and fields. Next I'll work on the initial prompt to be as descriptive as possible about the desired ui, color scheme and design concepts/approach, e.g., minimal, classic, Apple-esque, etc. Often I will look to other designs similar and see how they are described so I know how to prompt Bolt.

Lessons learned and challenges faced

Lessons learned

Some of the more foundational things I learned on this particular project:

• Bolt seems to do better when I can provide the initial db table/field list vs relying on it to figure it out.
  
• That said, if you try to feed it an entire scheme which includes every feature, it can be too much. Instead, I feed it the core tables needed for user management, roles, and if there is a core feature that is unique to the project, I will also include that. Then as the project progresses, I'm able to prompt each main feature's db table/field requirements. By breaking these into smaller bits, it helps keep the flow smooth.
  
• For more complex objectives, I've learned that it's actually more effective to simply describe it and let Bolt come up with a plan. For example, if I need to use a mapping api, but I'm unsure whether to do it front-end for an MVP or spend the time to go backend via Google api or something, it's better to have that discussion with Bolt vs just dictating which approach first.

Challenges faced

As with most Bolt projects, there are certain frustrations and idiosyncrasies with the development environment. Here are some general and project-specific ones I encountered:

• There is no clear path to creating a product support workflow that includes environments for dev > stage > production. While it may initially seem reasonable to simply replace the env info with a different db's keys, the issues around migration files, lack of Supabase support for comparing two db's and showing the diffs to apply to one from the other, and inability to clone Supabase storage for diff envs presents a challenge.
  
• Design prompts: I spent more time tweaking the design than typical and I would give Bolt very specific instructions, in short bits, accompanied with a screenshot of the desired outcome, but it would have difficulty achieving. It would often take multiple prompts to do simple things like reorder divs on a page.
  
• I was immobilized by repeated issues of hitting the project size threshold as well as failed prompts due to an error where it said the llm had reached its capacity. This caused days of delays and millions of tokens.
  
• Simply relying on the bolt ignore file to combat limits is not only time consuming but also it's often difficult to do because a task might cross so many folders that it becomes difficult to discern what should be in the file at a given time.

Accomplishments to be proud of

One of the trickier spots of the development is a requirement for a CRM contact to move through the pipeline, along with all the activity and interactions logged, and then become a customer, which has an entry in auth.users and a uuid. So the record must seamlessly meld the contact_id and user_id throughout the app.

Similarly, the requirements call for Organization, though an org can have multiple contacts associated with it, and has a primary contact if it is to become a customer. However, it's the user who has the customer account so the app must account for that fact in assignments, reporting and account management.

There was also the need to allow any account to have multiple addresses, with Orgs being the primary reason. So when a business signs up, there will be a primary contact who is the account holder but each address location might belong to different routes. So there will be a single contract for multiple locations but each location is handled somewhat independently. This, too, turned out to be somewhat interesting to implement.

Next steps

Next up for WasteWise is to:

• Polish the existing app and clean up any inconsistencies in the UI
  
• Solidify a workflow in order to be able to use the app in production
  
• Wire up Stripe and Postmark (which I did not do for the hackathon)
  
• Present to potential customers

Built With

• data
• database-functions-(rpc)
• database-triggers
• edge-functions-(deno-runtime)
• foreign-key-constraints
• frontend:-react-18.3.1
• geocoding-integration
• headless-ui-1.7.18-database:-supabase-(postgresql)
• lucide-react-icons-0.344.0
• multi-tenant
• multi-tenant-schema-design
• polymorphic-relationships-backend:-supabase-auth-with-jwt
• react-router-6.22.3
• role-based-access-control
• row-level-security-(rls)
• secure-password-management
• serverless-api-endpoints
• tailwind-css-3.4.1
• typescript-5.5.3
• vite-5.4.2