## Inspiration 💡

Let us start with a story. About one year ago, one of our teammates got a text message about a charitable crowdfunding campaign seeking donations that promised that all the money raised would go towards planting trees. Our teammate scrolled through their Facebook page and was impressed by their previous work greenifying areas in India. So he made a sizable donation to the campaign. However, he later learned that the pictures posted were scraped off the internet and he, along with several other people, was scammed by this fraudulent crowdfunding campaign.

Reflecting on that experience, we decided that we will only make donations to charitable campaigns if and only if they show us deliverables for the cause they support. However, **current crowdfunding platforms focus on raising money before the campaign takes actions.** By compelling campaigns to deliver on certain milestones, we can **effectively prevent fraud because donations do not take place until evidence is provided.** We were willing to donate only after certain milestones were achieved by the campaign.

*To facilitate a transparent deliverables-based transaction between donors and charitable crowdfunding campaigns, we created* **Fintruist** ✨

![TopBar.png](https://i.postimg.cc/mkNgL4mp/TopBar.png)
![prev-topbar.png](https://i.postimg.cc/6QPQpYtR/prev-topbar.png)

![break](https://res.cloudinary.com/devpost/image/fetch/s--B0JC0SQ_--/c_limit,f_auto,fl_lossy,q_auto:eco,w_900/https://ipfs.infura.io/ipfs/QmaNVVQELQk7EVBZRCWhNbdxDbMBVU5a4koeH7yBK1dojC)

## What it does 🤔

**Fintruist** is a *decentralized crowdfunding application* that uses bleeding edge-technologies to fight against Scams and Frauds in the name of Fundraising and Crowdcampaigns.

![what-it-does2.png](https://i.postimg.cc/SNVkKDGs/what-it-does2.png)

On **Fintruist**, charitable organizations can create campaigns that allow users to donate *fixed amounts*. *But donations will* **only be executed after the donors verify the deliverables** *that were promised by the organization*.

![Userflow.png](https://i.postimg.cc/wBJ0FxFG/Userflow.png)

![break](https://res.cloudinary.com/devpost/image/fetch/s--B0JC0SQ_--/c_limit,f_auto,fl_lossy,q_auto:eco,w_900/https://ipfs.infura.io/ipfs/QmaNVVQELQk7EVBZRCWhNbdxDbMBVU5a4koeH7yBK1dojC)

## How we built it 🦾

* **Frontend:** ReactJs, Tailwind CSS
* **Backend:** Solidity, Truffle, IPFS, Web3.js
* **Tools:** Auth0, Botdoc.io, Dasha, Moralis
* **Design:** Figma, Illustrator, Photoshop, After Effects

For Blockchain Network, we went ahead with ETH & Wei.
![Chain.png](https://i.postimg.cc/G2S54gpF/Chain.png)

And several other 3rd party services & testing tools & obviously GitHub as VCS.

![tech-stack-Devpost.png](https://i.postimg.cc/GtGxbXTh/tech-stack-Devpost.png)

![break](https://res.cloudinary.com/devpost/image/fetch/s--B0JC0SQ_--/c_limit,f_auto,fl_lossy,q_auto:eco,w_900/https://ipfs.infura.io/ipfs/QmaNVVQELQk7EVBZRCWhNbdxDbMBVU5a4koeH7yBK1dojC)

## Team Discord Usernames

* chief\_of\_mischief#8050
* Hogo101#3616
* Neel#0242
* EndofLeTime#6747

## Social Good 👨🏻‍🤝‍👨🏽

*We began this hackathon with a singular mission*: **To facilitate deliverables-based donations to prevent donors from falling for scams**. A government study estimates that **annually $15 million are lost** in *charitable crowdfunding campaigns*. We want to stop this money leak. Preventing the said hefty amount from being lost in these scams is $15 million more being devoted towards causes for social good.

Moreover, our long term aim is to win the trust of donors so that they feel confident to donate larger amounts and increase the total number of donors of social good in this world!

*We are a team of* **4** *driven to build technology to promote* **social good**.

![Mockup.gif](https://i.postimg.cc/PqW6tFmV/Mockup.gif)

---

## Design 🎨

Our Figma file consists of Wireframes, Mockups, and Design Documents we used to build our application.

We were heavily inspired by the revised version of **Double-Diamond** design process, which not only includes visual design, but a full-fledged research cycle in which you must discover and define your problem before tackling your solution & then finally deploy it.

![Double-Diamond-1.png](https://i.postimg.cc/B6qjjNzn/Double-Diamond-1.png)

>
> 1. **Discover**: a deep dive into the problem we are trying to solve.
> 2. **Define**: synthesizing the information from the discovery phase into a problem definition.
> 3. **Develop**: think up solutions to the problem.
> 4. **Deliver**: pick the best solution and build that.
>
>
>

This time went for the minimalist **Tailwind** inspired design. We utilized design tools like Figma, Photoshop & Illustrator to prototype our designs before doing any coding. Through this, we are able to get iterative feedback so that we spend less time re-writing code.

![figmacrop.png](https://i.postimg.cc/P5SD1gm8/figmacrop.png)
![color-palette.png](https://i.postimg.cc/J4mHvrxk/color-palette.png)

![break](https://res.cloudinary.com/devpost/image/fetch/s--B0JC0SQ_--/c_limit,f_auto,fl_lossy,q_auto:eco,w_900/https://ipfs.infura.io/ipfs/QmaNVVQELQk7EVBZRCWhNbdxDbMBVU5a4koeH7yBK1dojC)

## Research 📚

Research is the key to empathizing with users: we found our specific user group early and that paves the way for our whole project. Here are a few of the resources that were helpful to us —

* <https://bit.ly/3qXELlA>
* <https://bit.ly/3jh0IIt>
* <https://bit.ly/3u1gFbE>
* <https://bit.ly/3NIetO8>

## Best Use of Dasha AI 👂

Given that Web 3.0 is still in the infancy stage, we believe that decentralized applications need constant feedback on user experience to disrupt their Web 2.0 counterparts. To *get feedback*, we use Dasha SDK to create **a chatbot that collects feedback from donors on our platform**.

## Botdoc 🤖

The *donations in our application need to be securely logged for our donors* **so that they have a chance to review their donations later**. To send receipts securely, we use the **Botdoc API** to send a receipt to users after they approve a donation. Given the ubiquity of mobile phones, we also send a message to the user using Botdoc's messaging API with the receipt attached. **Botdoc's API has allowed us to reinforce our mission to become the safest and most secure crowdfunding platform.**

## Auth0 🔐

Auth0 was used to integrate seamless login via **SSO**, and we even use Multi-Factor Authentication to have a Secure sign-in. This is important to prevent spam, fraudulent, charitable crowdfunding campaigns from flooding our application.

## Best Domain Name from Domain.com 🌐

* `deliverables-based-donations.space`

## 🏅 Accomplishments that we're proud of

We are proud of finishing the project on time which seemed like a tough task as we had so many features to implement. Moreover, we learned a lot about AuthO, Dasha, BOTDOC.io, new web3 technologies, and libraries that we could incorporate into our project to meet our unique needs. And as always, working overnight was pretty fun! :)

## 🧠 Challenges we ran into

This project was especially an achievement for us because this time the experience was very different than what we have while building typical hackathon projects, which also includes heavy brainstorming, *extensive research*, and yes, hitting the final pin on the board.

We tried to incorporate several *Web 3.0 technologies* and this was challenging since half of the team's forte was in Web 2.0 technolgies\*.

Special thanks to — *Rafael from Botdoc* [**Rafael Juzwiak#3199**] 🤗

## What we learned 📖

**Proper sleep is very important! :p** Well, a lot of things, both summed up in technical & non-technical sides. Also not to mention, we enhanced our googling and Stackoverflow searching skill during the hackathon :)

## What's next for Finturist 🚀

*We believe that our App has great potential*. We plan to expand it's capabilities by *incorporating other languages*. Our next step is to expand the number of variables taken into account in our algorithm. Besides, creating a mobile app is also on our mind which will surely amply the count of audience base from across the globe.

**Note ⚠️ — API credentials have been revoked. If you want to run the same on your local, use your own credentials.**

![footer.png](https://i.postimg.cc/xTkBrQd9/footer.png)
## Inspiration

Fashion has a waste problem. The fashion industry is responsible for 10% of annual global carbon emissions. The problem of excess product is endemic in the garment industry, now costing the US retail industry as much as $50 billion a year. It has led to constant discounting, dumping of unsold clothes to lower-income countries and in the worst case, stock destruction i.e. burning of perfectly wearable clothes.

So, we came up with F•sync.

F•sync aims to address this fashion waste issue by enabling an inventory management tool that provides an accurate view of a brand’s total inventory and can be easily shared with all retailers, giving them the possibility to request any item they need with just one click. Rather than directly ordering from brands whenever stock is out and forcing the brand to manufacture more products, retailers will be able to request unsold/excess stock from other retailers. So, fewer products are manufactured and potentially wasted as a result.

This project is inspired by API integrations for inventory management across platforms like Shopify and Woocommerce. The solution is simple and efficient for brands working with retailers who also use these platforms and have them integrated amongst their POS (point of sale) systems.

## What it does

F•sync helps brands facilitate inventory in real-time across sales channels. In a single place, all their retailers have live access to stock across other retailers and give them the possibility to request any item they need with just one click.

Retailers can manage their own store inventory, which is automatically synchronized with a brand's global inventory. Retailers can also view other retailers carrying a specific product, so if they run out of product, they can request it directly from another retailer that carries the same product or order from the brand themselves—all in one place!

Brands can add retailers to have their inventory be tracked in their global inventory, as well as add new lines of products to their inventory which retailers can see and request. They can likewise request product from other retailers.

## How we built it

F•sync is divided into two parts: the client frontend and the server backend.

We used Express for our backend webserver, and “Socket.io” to communicate between the frontend and the backend, and “MongoDB” for our database. We also incorporated the Twilio API (SendGrid) to send emails personalized through dynamic templates to the various companies that would use our product. For MongoDB, we are using two collections: one for brands and one for retailers. Each brand has basic information, a list of products with their global quantity and name, and a list of associated retailers. Likewise, retailers have basic information, but also have a list of brands they carry and a list of products in that specific brand they carry. This enabled us to minimize having the same information repeated and make it easy to look up any information about any brand or retailer, such as their inventory.

For the frontend, we used React JS combined with the Chakra UI and opened up "socket. io-client" connections to the backend. We chose sockets since, when events happened in the frontend, we can trigger other clients through events to update their view, enabling a real-time reflection of the global inventory of a product

## Challenges we ran into

This is one of the most significant projects we have ever done due to the amount of coding required. It's also the most complex web app we have ever developed. Normally, designing a large database schema and working with so many operations to modify many different parts of the database and synchronize everything together will take far longer than the scope of a short hackathon—the time and effort to write and test everything that we needed to access the database might be impossible to accomplish in 36 hours. It was a challenge to meet the 36 hour deadline, but doable if we planned everything out function by function, which it greatly aided in developing the reusable code that we needed for multiple database operations. As a result, we are amazed and proud of each of us and by the results of this project!

Aside from database accessing, integration of frontend and backend was also a very challenging part of the project. With so many planned features and complex interactions in our app, we had a monumental amount of events we had to account for and test on the frontend. Using sockets and React's context hooks took some figuring out.

## Accomplishments that we're proud of

We are incredibly proud of one of our front-end members for learning how to use React.JS in 36 hours with Chakra UI. There were hundreds of lines of coding that made it look very challenging to do, and the project was enormous for 36 hours of coding. For the backend, there were more than 800 lines of code, and we had numerous fully developed pages in our frontend. Overall, this was the most complex project we've done. One thing that we're especially proud of is that we managed to correctly connect the front-end with backend coding and enable most features we planned on having. Though, we had to plan everything out thoroughly to make it possible to build our app in this period. Everyone here contributed the same amount of energy and time to make this project possible!

## What we learned

In tackling this project, we learned the importance of sitting down, whiteboarding, pondering, designing the entire project and backend from scratch before starting. For a hackathon, a rough plan is often developed and there's a rush to start coding and figure it out as we go through the coding process. For the scale of our product, it would be impossible to wing it successfully in a limited amount of time.

And when it was time to start coding, it was really easy to follow the plan laid out. As a result, some of the code had relatively few errors despite a large amount of code that we wrote. When any issues arose, previously flagged problematic areas we identified in the planning process helped us debug and fix things faster.

Lastly, it was also a challenge for a member of our team who learned React JS in 36 hours and contributed a fantastic amount of work. Overall, success comes from learning from mistakes and knowing how to adjust them.

## What's next for F•sync

We will try it out with some brands to test the potential integration across different software platforms (e-commerce, POS, and other inventory management solutions). F•sync could become the next-generation inventory management app that provides smart production and inventory allocation analytics by unlocking the capabilities to ship-from-store, in-store track in real-time, and process payments. Helping brands reduce overstocking and overproducing, one step at a time.
## Inspiration

One of the biggest problems we constantly have faced when interacting with insurance companies lies in the process of filing and receiving insurance claims. When one of our team members got into a huge traffic accident (luckily everyone was safe), they had to wait over 5 weeks before they got their claim back for their damaged vehicle. After hearing this, we knew we had to pursue a fix for this extremely lengthy claim process.

## What it does

Autosurance is meant to integrate into an auto insurance firm's claim process. Typically, there are three very time-consuming steps in filing for and receiving a claim. This process is automated effortlessly with Autosurance, where you can file for a claim, have it verified, and get your money back to you--way faster.

## How we built it

Our machine learning solutions were solely created using AWS SageMaker, which provided a really convenient way to train and create an endpoint for our two models; one of which is for crash verification (image classification), and the other which is for cost analysis (regression). These endpoints were linked to our software's backend using AWS Lambda, an extremely convenient gateway connecting AWS and our website. Our CRUD operations run on a Flask server which acts as an intermediary between our AWS S3 buckets and our ReactJS front-end.

## Challenges we ran into

We faced a lot of problems setting up AWS Sagemaker and getting Lambda to work, as all of us were extremely new to AWS. However, with help from the awesome mentors, we managed to get all the machine learning to work with our back-end. Since our project has such a diverse stack, consisting of AWS (Sagemaker, Lambda, S3), Flask, and ReactJS, it was also quite a challenge to integrate all of these components and get them to work with each other.

## Accomplishments that we're proud of

We're really happy that we ~~managed to get decent sleep~~ were able to create an interesting solution to such a far-reaching problem and had *tons* of fun.

## What we learned

We learned tons about using AWS, and are really happy that we were able to make something useful with it. All of us also got some great first-hand experience in developing a full tech stack for a functioning app.

## What's next for Autosurance

We want to have Autosurance integrate into a current insurance platform's web or mobile service, to be able to perform its intended use: to make filing and receiving claims, really frickin' fast.