YesPlz

Overview

YesPlz is an AI-fueled search interface that mirrors the way people naturally shop and search for a product.

The Requirements

They wanted to build an MVP product for their first pitch deck in only 2 weeks.

My job was to build their web interface using React ecosystem and integrate it with the visual search engine on the backend. I built the frontend app starting from the MVP phase until the v1 early release.

The Challenges

I joined the team when they were still in a proof of concept stage.

The existing frontend code they had was pretty basic, an HTML and 1 monolithic javascript file to interact with their SVG elements for visual filters. It does make sense since they were focused on building the AI search engine first (backend).

The Process

I started the frontend codebase with a quick simple setup using create-react-app, then uses Redux for the state management.

Why redux? I knew that the MVP requirements were only 4 screens and it even had no authentication feature yet. It definitely can be done easily without a state management library at all, right? But when I tried to discuss with them how this MVP will grow in the near future, the final answer is always the same. Sooner or later we will end up needing it. So why don't we invest in it from the beginning?

The other advantages of using redux, it will make our code looks cleaner, scalable, and easier to test. It did become a good decision in the end, since their web application grew quickly in just a few months. Especially when we decided to separate the web and mobile web codebase in a mono-repo. By using redux, we were able to smoothly migrate our codebase to mono-repo easily and share the state, selectors, and actions with just a little refactoring.

The main reason we chose to split the codes between web/mobile-web instead of just relying on “responsiveness of the web”, is because we had more complex features on the web that could make the builds bigger for mobile-web without adding more value to it. We didn't want to just "hide" features that users will never use, we want to remove them completely from our mobile web. That's why we use Lerna, so we could share only the codes we needed for both sites so it won't sacrifice the user's experience with the platform.

As for the Visual Builder, I didn’t want to rewrite the codes that were already there since we have a strict deadline. So I decided to refactor the code instead, make it more manageable. I also added SnapSvg to helped me to quickly add interactions to the visual filter and pouring some animations into it. The best thing about snapSvg, it has lots of features and helpers. So I ended up removing almost 40% of the previous code. As you already know, less codes = less bugs!

The Deployment

They previously deployed their site manually on AWS instance. To integrate their backend service with the frontend app, I created a dockerized container and uses nginx server to serve the static files and manage the proxies for the search engine service. The deployment became even easier to do, with just a single command (docker-compose) the web & mobile app will be transpiled and served.