Update README with live version

README.md

@@ -14,7 +14,6 @@ For an application like this, my candidates were
 
 So based on this, my two top candidates were Gatsby & Next.js, I decided to go with Next.js because of personal preference :)
 
-as a side note the api doesn have cors configured correctly, so i couldnt query directly from fe, and for the challenge i set up a proxy to bypass this
 Aside from my reasons of choosing Next.js, I ended up creating a proxy for the API, since every request from a client application to `https://prisma-fe-dev-assignent.vercel.app/api/` was blocked by CORS policy (this was a workaround to get the API working).
 
 I added the option to choose between the original API or the proxy: adding the env variable `NEXT_PUBLIC_API=https://prisma-fe-dev-assignent.vercel.app/api` would make the client application to use the original backend instead of using proxy.
@@ -33,16 +32,20 @@ yarn dev
 
 Open [http://localhost:3000](http://localhost:3000) with your browser to see the result.
 
+## Live version
+
+You can also find a live version [here](https://prisma.inama.dev/)
+
 ## Feedback on the API
 
 There are a couple of things that I would do differently if I could change the API:
 
 1. Change CORS policy to allow fetch by any origin (only because this is a public API)
 2. Improve responses:
-   a. Server should return client error responses (40X) if the data was invalid, not 500 (Server error response).
-   b. It would be nice if `/login` endpoint returns user data instead of just a message
-   c. Double check message content (there was a tiny typo in the failed response for `/login`)
-   d. I would change the result of `/user/{id}` to return a user with an `id: int` instead of `id: string` to keep consistency with the other endpoints.
+   - Server should return client error responses (40X) if the data was invalid, not 500 (Server error response).
+   - It would be nice if `/login` endpoint returns user data instead of just a message
+   - Double check message content (there was a tiny typo in the failed response for `/login`)
+   - I would change the result of `/user/{id}` to return a user with an `id: int` instead of `id: string` to keep consistency with the other endpoints.
 
 ## Improvements