diff --git a/README.md b/README.md
new file mode 100644
index 0000000..c476b99
--- /dev/null
+++ b/README.md
@@ -0,0 +1,142 @@
+# x-lab-lbq
+
+## Overview
+This is a very simple implementation of a standard datafetching backend-frontend piece. It may seem very simple and not very feature rich (and look quick ugly!), however I feel like it's a good representation of the approches I would take to a brand new full stack application, without implementing all of the future features.
+
+It shows the CSV data given as a simple grid, where the user can filter based on tags and categories.
+
+## Technology Used
+
+### Backend
+* .NET Core 6 - ASP.NET API
+* Entity Framework
+
+### Frontend
+* Vanilla React w/ Vite
+* React Query - React Router
+
+### Development Tools
+This project was primarily developed on Kubuntu 22.04, but has been tested on Windows 10.
+
+* .NET 6
+* NodeJS v16.17.0
+* Rider 2022.2.3 (.NET)
+* DataGrip 2022.2.5 (Database)
+* WebStorm 2022.2.3 (React/FE)
+* VSCode 1.72.2 (React/FE/Docs)
+* Insomnia
+* Misc KDE tools
+
+## Setup
+
+Brief instructions on how to get the solution running locally. There was not enough time to get deployment scripts written, so only dev-mode is supported at the moment.
+
+Prerequisites:
+* .NET 6 SDK
+* NodeJS (I used v16.17.0, so any >=v16 should work) w/ NPM
+
+### Backend
+
+#### Migrations
+
+First, make sure the database is created and migrations are run correctly. The backend uses standard EF migrations that can be completed by running the following commands:
+
+First, assure the entity framework tool is installed (and that you have the .NET!):
+```bash
+dotnet tool install --global dotnet-ef
+```
+
+**The following should be run in the `./backend/LeedsBeerQuest.API/LeedsBeerQuest.API/` directory** -
+
+Then run the migrations, this will also create a local SQLite database that the app will use (in the default directory):
+```bash
+dotnet ef database update
+```
+
+#### Data Seeding
+
+Data seeding is something I've done in projects before (usually through EF migrations), however it seemed to have issues with test data and testing scenario constants (particularly using an in-memory database). Feel free to checkout the seed data migration commit [here](https://github.com/Stedoss/x-lab-lbq/commit/add80a3521495445f9e5abb9cfe399c80d28e6c7) to see what the seeded migration looks like.
+
+The database should seed automatically when launched for the first time, if compiled with the `LBQ_SEED_DATA` constant. It will read the `leedsbeerquest.csv` from the `LeedsBeerQuest.API` directory. It will only seed the database with the CSV data if there is no existing data in the database.
+
+#### Running
+
+To run the application, navigate to the `./backend/LeedsBeerQuest.API/LeedsBeerQuest.API/` directory and run:
+```bash
+dotnet run
+```
+
+This will run the application at https://localhost:7021/ (assuming the default config is used).
+
+#### Running tests
+
+Only standard unit tests are included.
+
+To run the tests, navigate to the `./backend/LeedsBeerQuest.API/LeedsBeerQuest.API/` directory and run:
+```bash
+dotnet test
+```
+
+### Frontend
+
+#### Running
+To run the development version, navigate to the `./frontend/leeds-beer-quest/` directory and run:
+```bash
+npm run dev
+```
+
+#### Building
+To build the production version, navigate to the `./frontend/leeds-beer-quest/` directory and run:
+```bash
+npm run build
+```
+
+This will produce a build that can be deployed (sorry for no instructions on deployment!).
+
+#### Environment Settings
+
+The `./frontend/leeds-beer-quest/src/lib/environment.ts` file should already contain the correct location for the backend API, however if it does not you should modify the `BaseAPIUrl` property to be the same path as your backend instance.
+
+## How can I improve?
+
+### A Better Seeder
+
+The seeding mechanism isn't great. I would probably like to have kept them as migrations if I hadn't run into issues during development.
+
+### Microservices
+
+There are three clear entities that could be split out into microservices (they might be a *little* too similar to split them out, however it should be considered), Venues, Tags and Categories. I *personally* wouldn't split them out, but I can see the benefits of maintainability.
+
+### More and better tests
+
+Only unit tests are included, which are good however integration and automated tests would be ideal for production software.
+
+### DTOs
+
+Returning raw database objects as responses isn't really ideal (and I found an issue with many-to-many relationships which causes an infinte loop in the JSON parser!), so it would be ideal to use DTOs when returning objects from the API.
+
+### More and better configuration
+
+Right now, there's little in the way of user configuration. Ideally, most 'environment' variables would be configurable either through the `appsettings.json` file or through environment variables.
+
+### A better UI
+
+The UI isn't great, and doesn't really do its purpose of displaying data in a good way for a user.
+
+### Better error handling
+
+More for the frontend, but backend doesn't have the best either. More checks make the user experience much better.
+
+## What NEEDS to change
+
+### Add unit tests for FE
+
+Even if it's just a few, it will show off how I unit test for the frontend.
+
+### A little better configuration for seeding ect
+
+Just to say I have.
+
+### Make tags work
+
+The last big thing.
\ No newline at end of file