Link to Application published on Heroku

Link to Github Repo

This application has been developed as part of the requirements of T2A2 at Coder Academy in Brisbane. The assignment involved the development of a two-sided marketplace platform as a way of demonstrating ability to design and develop an application from the ground up, through to deployment. Part of the requirements for this assignment involved solving some kind of problem that exists in the world today.

Between 1961 and 1994, the number of houses in Australia more than doubled from 2.8 million to 6.7 million. (The Evolution of Australian Home Building) Due to modern updates and discoveries in building materials and regulations, it is forecast that the amount of renovations needed to be completed on houses built in this time will be rapidly increasing in coming years. (Australian Renovation Cost Guide)

In Australia in 2016, nearly 8.4 million people (62%) of Australians conducted some kind of DIY home renovation. (Renovation Nation: Home Improvement in Australia) It is a well documented fact that Australians love a Saturday morning trip to Bunnings, with the company reporting revenues in excess of $13.1 billion in 2019. As such, it can be reasonably concluded that there is substantial demand in the Australian market for access to tools and hardware in order to complete DIY projects and renovations.

Outside of professional tradespeople, many DIYers wouldn’t need access to this hardware beyond the timeframe of their projects. Yet, of the 8.4 million people who undertook DIY projects, more than 2.2 million (26%) spent more than $5000 on these renovations. (Renovation Nation: Home Improvement in Australia)

By having access to the tools and hardware required at a cheap rate, for the duration of a project, Australian DIYers can get more ‘bang for their buck’ when it comes to undertaking renovations. Wesfarmers - Bunnings Although businesses such as Kennards Hire exist to fill this gap, the profit-driven nature of the business means costs of these services can sometimes be high enough that it’s more beneficial for someone to purchase the tool. In instances where people do purchase tools themselves, it is extremely likely that they won’t be using them most of the time, regardless of whether hiring costs made an impact on that decision.

Mates Rates solves all of these problems at once by providing a platform for tool owners to rent out their hardware to those looking at completing DIY projects. Tool owners can earn money from hardware that ordinarily would be collecting dust, while DIYers will be able to use tools at a significantly cheaper rate than the options that exist in the market already.

Leveld is an application that already exists with similar functionality, but appears to have a relatively low user count. Widespread adoption is critical to the success of this product and I believe that Leveld has failed to achieve this (so far) due to the fact that the product hasn’t been marketed correctly.

By focusing exclusively on an Australian audience, where DIY is ingrained into the culture, Mates Rates should be able to capitalise on the market and provide an extremely valuable service to Australian DIYers.

Mates Rates is an application that serves as a platform for users to rent out tools to other users for use in DIY projects. The application provides significant value to both tool owners and tool renters. Tool owners can earn money from their tools which would ordinarily not be receiving much use. Tool renters gain access to the hardware for their job without having to pay extreme prices.

The application has a number of high-level components that compliment one another to deliver a smooth user experience which allows the users to get the maximum value from the application.

Providing a platform for tool rental is valuable to users, but without proper channels for users to report and record issues that they may have (such as stolen tools), the application should not be developed beyond the scope of this assignment. In the event that this does happen, additional authorisation would be required on sign-up for different users depending on what is required.

Rails Version: 5.2.3

Ruby Version: 2.6.4

Ruby on Rails (Rails) is a web application framework built using the Ruby programming language. Rails uses what is known as the Model-View-Controller (MVC) software architecture pattern. The MVC structure breaks code down into individual pieces to maintain separation of concerns. The model stores our data, the view displays it and the controller connects the two and contains most of the logic in an application.

Within Rails, there are a number of different pieces that were used to handle certain parts of the application.

PostgreSQL version: 10.10

An object-relational database system based on the SQL language, PostgreSQL was selected for database management.

The Ruby language (and by extension, Rails) uses Gems as a way of easily using preexisting code to implement certain functionality within an application. Rails uses a whole host of Gems by default, below is a list of Gems installed in addition to the defaults to assist with the development of Mates Rates.

Google Maps API

Google provides a massive range of services which can be utilised through API calls. The services all relate to locations, routes and distances.

Cloudinary

Cloudinary is an asset hosting and management tool that utilises a Content Delivery Network (CDN) for improved and automated file handling within our application.

Cloudinary’s CDN offloads the bandwidth-hungry process of delivering assets to a user away from your website and into the cloud, where it is delivered and optimised dynamically. Cloudinary optimises for device, browser and bandwidth requirements.(Cloudinary - File Upload Storage)

Assets are delivered securely over Transport Layer Security (TLS) or Security Sockets Layer (SSL). - (Cloudinary - File Upload Storage)

Heroku

Heroku is a platform as a service (PaaS) based on a managed container system with integrated data services. - (Heroku)

Heroku supports a wide range of languages and frameworks and allows developers to quickly and easily host their application on a live server using containers. (Heroku Platform) Containers are used to host multiple applications on a single server, while keeping them completely separate from one another. In Heroku’s case, these containers are known as “Dynos”.

Dynos are isolated, virtualized Linux containers that are designed to execute code based on a user-specified command. - (Heroku - Dynos)

Dynos are incredibly useful for scaling applications depending on how much traffic your application is seeing, and subsequently how many resources you require. (Heroku - Dyno Scaling)

Heroku makes deployment incredibly easy by having automated Dyno building (provided the application framework is supported by Heroku). Essentially, all of the complex setup is performed automatically by Heroku behind the scenes. (Heroku - Dyno Buildtime)

Heroku serves as a remote Git repository which means development updates can be pushed to Heroku as you would any other remote repo.

This means Heroku also has the ability to rollback the application to a previous iteration using each deployment as a release. Technically, however, Heroku does not rollback to a previous release, but builds a new release based on the release specified for the rollback. (Heroku - Releases)

Heroku also provides a whole host of other services and features for developers to use, but given the relatively simple nature of the Mates Rates MVP, most of these were not needed for this stage of development and deployment. (Heroku - Managed Data Services)

Github

Github is a company that provides free remote repository hosting utilising the Git version control system.

Git tracks changes in the application source code in order to manage project development and smooth developer collaboration by automatically handling merges and updates to the code base.

As this project only had a single developer, Github was purely used as a remote storage solution and version control system.

Google Fonts

Google Fonts is a service provided by Google that allows for developers to use different fonts within their applications distributed across the web.

Google fonts are optimised for speed using caching across websites that make use of the service. If a user has visited a website making use of a Google font that you are using as part of your application, the font will just be loaded from the user’s cache. (Google Fonts - About)

As a bonus, the vast range of fonts that Google provides allows applications to use well designed fonts that improve usability and aesthetics.

Rails uses Active Record associations to set up and determine the relationships between models in our database.

Relational databases use what are known as foreign and primary keys to help establish these connections between models.

Database Schema Design

Database ERD

As can be seen in the ERD, within Mates Rates the User is the foundational model upon which the application is built. Without the User model as a starting point, all other models have no point of ownership for their existence, whether direct or indirect. In the context of Mates Rates, a Tool must be owned by a User, it doesn’t make sense for a tool to exist without one. Subsequently, if Tools don’t exist, Rentals and Categories existing also doesn’t make sense. In much the same way, if Users didn’t exist, the Role model has no point of reference either.

The User model contains data relating to personal information of a user. As shown in the ERD above, this information is as follows;

The user_id is automatically generated as part of Rails and Devise and used to distinguish instances of the User model. Because user_id will be unique, it is a great way of referencing specific user instances. As such, the user_id is used as the primary key (represented as ‘PK’ in the left-most column of the User table within the ERD).

When signing up, users will need to specify a password used for logging in to the application. This password is automatically encrypted by Devise using bcrypt, meaning that the password is never stored in plain text. Within PostgreSQL strings are stored under ‘character varying’ columns within the table.

Each user will sign up using their email address, this email address will need to be unique amongst users.

User’s will also be required to set a first_name when signing up so that other users will know who they are when renting tools to one another.

User’s also set a last_name when signing up. Both first_name and last_name are used to identify users as they use the application. These fields do not need to be unique amongst users.

Users are required to enter an address on signup so that rentals can be managed between users. The address field on signup provides an autocomplete funcrtion using Google Maps API in order to push users to store addresses in a recognisable format so that later calls can be made.

Similarly to the User model, the tool model is also critical to the functionality of Mates Rates. Without Tools, there is no reason for the application to exist.

Much like User, there are other models that are dependent on the existence of the Tool model also.

The tool_id behaves in an identical fashion to the user_id. It is used to keep track of and identify instances of the Tool. As can be seen in the ERD, this is also the primary key for this table.

Each Tool must have a price associated with it so that users will know how much it will cost them to rent the tool. As outlined in features, tools are rented out for a minimum of a day to keep it easy for owners to manage their tools. Therefore, the price data will refer to the cost per day of a rental. Because of this, we can be sure that the overwhelming majority of prices will be able to be represented as a whole dollar value, meaning we can store prices as an integer, rather than a decimal.

Fairly self explanatory, this refers to the name (or type) of product. If you have a power drill, this will be ‘Power Drill’. This data is mandatory - although an argument could be made that an image is enough of an identifier, the user experience would be less than optimal.

Many different products make many different and overlapping products, as such we need to allow the user to specify who produces the tool they want to rent out. Similarly to the name field, this data is mandatory so that people can easily see what they are renting.

Different brands often produce different types of the same product to cater to different audiences. The drill that a professional tradesperson uses will likely be different from the average consumer-level drill, despite being produced by the same brand. As such, we need to allow users to specify a model name or number. However, unlike name and brand, this information is not mandatory. Sometimes the model number is unknown, but more importantly, not every product will have a model number!

In the likely event that there needs to be some more identifying information posted about the tool, a description field is provided so that user can enter in any information that they want. The text type specification allows for larger amounts of text to be input when compared to a string. This is used as it is more than possible for a description to become quite lengthy.

A user may want to perform some kind of admin/preparation work before allowing their tools to be rented out. As such, allowing them to specify whether the tool is available will be used to prevent it from showing up to other users. Given that this is only a yes or no option, we can represent this data with a boolean.

If a user is willing to deliver their tool to someone who is renting it, we can let them specify that delivery is available. However, there may also be instances where delivery is the only option - the tool may need to be transported in a specific manner. If this is the case then users will also need to be able to specify that only delivery is available. Although this could be stored differently, storing it as a string allows for easy validation.

If a tool has a delivery option users need to know how much it will cost to have it delivered. Therefore, a delivery fee is needed. A tool owner will not know the delivery distance before someone rents the tool so users will need to specify a fee per km. Given that the distances will vary and be much more specific compared to rental days, this fee will be stored as a decimal.

It may be unfeasible for someone to deliver a tool across a short distance if there is a lot of setup that goes into transporting it. As such, users will be able to specify a minimum to make sure each delivery is worth their while. As with the delivery_fee itself, this is also stored as a decimal.

Finally, as each tool must belong to a user, being able to identify which user the tool belongs to is critical. As such, the user_id (with the integer type), is stored in the Tool table. As can be seen in the ERD, this is a foreign key. The foreign key points to the user_id of the tool owner.

As with the previous models, rentals have a unique id that is used for identification of certain instances of Rental. As shown in the left hand column of the ERD, this is also the primary key for Rentals.

Rentals are only allowed to go for a certain amount of time, as such dates need to be specified to indicate when this period is. As dates are often used in databases, a date type exists, which is what will be used to store the start date.

The end date behaves in exactly the same way as the start date, but (as the name suggests) specifies the end of the rental period, not the start.

Given that the rental transaction is not an immediate, single event trigger, there needs to be some way of specifying that the rental period has been completed successfully. As such, a boolean value will be set to track this status. Once the tool owner has indicated that the tool is returned, this value will update.

Delivery fees are calculated using the Google Maps API. By passing the address of the user and the tool owner to the Routes Distance Matrix API, we can determine the distance between them (importantly: via routes - not 'as the crow flies'). Using the calculated distance, we multiply it by the tool's delivery price to get the delivery fee.

Similarly to delivery_fee, price is dynamically calculated based on the length of a rental and the price of the tool. However, given that they are static values, no API calls are needed - just a bit of math. As tool price and number of day will both be integers, we can keep this as an integer.

Depending on the delivery options available for the tool, the user can choose between pickup and delivery. Although only two possibly options are available, this is stored as a string for easy comparison to the delivery options of the tool.

Each rental must reference a tool, because if there is no Tool being referenced, there is no reason for the rental to exist. The tool_id is tracked as a foreign key with the type integer to identify which tool the rental refers to. The label ‘FK’ in the table represents that this is a foreign key.

As with the tool_id, each rental must belong to a user, so that the person renting the tool can be identified. In the same way as the tool_id, the user_id is tracked as a foreign key with the type integer, as can be seen in the ERD. As two separate foreign keys are referenced within the Rental table, it is technically a join table. However, as there is additional information that it also holds it is used slightly differently when compared to other join tables (such as RolesUsers and CategoriesTools). This has been identified in the ERD by using a slightly different colour to the other join tables.

As with all models, Roles have a unique id that is an integer and functions as the primary key. This can be seen in the ERD left-most column, where it is specified as PK.

In order to track and manage specified roles in an easy to understand way, a name is assigned with the type string to each Role.

Rolify allows Roles to be assigned to multiple different models. In the case where this happens, the resource type indicates which model the role is being applied to. This model name is stored as a string.

In order to identify which instance of a resource_type the role is being applied to, the resource id references the id of this instance, stored as an integer.

As a user can have many roles and a role can be assigned to many users, a join table is required to indicate all of the assignments. Within the table, a column containing user_id’s matches up to the a column containing the role_id to indicate which role and which user are linked (and vice versa). The ERD shows that the user_id is a foreign key (FK), to indicate that it points to the user_id primary key.

All of the above relating to user_id also applies to the role_id. As can be seen in the ERD, it is also a foreign key.

As can be seen in the ERD, like the other models, categories also have a unique id that serves as the primary key for the category table.

In order to identify the category, a name is stored as a string to easily track and manage the different categories that are created.

As a category can have many tools and a tool can be assigned to many categories, a join table is required to indicate all of the assignments. Within the table, a column containing category_id’s matches up to the a column containing the tool_id to indicate which category and which tool are linked (and vice versa). The ERD shows that the category_id is a foreign key (FK), to indicate that it points to the category_id primary key.

All of the above relating to category_id also applies to the category_id. As can be seen in the ERD, it is also a foreign key.

Within Rails, there are six different types of associations that can be used. Rails Active Record Associations

The belongs_to association is used to set up one side of a model association such that one instance of a model (as the name suggests) belongs to an instance of a different model.

In the case where a belongs_to association is being used to set-up a one-to-one exclusive relationship, the has_one association can be used to signify that a model owns or contains an instance of another model. In other words, it is used to specify the belongs_to association from the opposite perspective.

In the case where a one-to-many relationship is required, the has_many association is used. It functions in the same way as a has_one, in that it specifies the belongs_to association from the opposite side, but instead of referencing only a singular instance, the model that has_many of another can contain or own multiple instances of the other model.

By specifying that a model has_many :through a different model, it indicates that the first model has_many instances of a second model by referencing a third model which has identifying information relating to the other models. Typically, this is used to set up what is known as a many-to-many relationship.

The has_many :through association can also be used to set up quick references through other has_many associations that may already exist between models.

Similarly to the has_many :through association, has_one :through specifies a one-to-one relationship between two models using a third, intermediary model that references the other model.

A has_and_belongs_to_many association specifies a many-to-many connection without the need for the third model to exist. It uses what is known as a join-table to indicate which instances of each model relate to which. Active Record handles all of the ‘joining’ automatically when using a has_and_belongs_to_many association. has_many :through associations also use join tables also, but they are manually specified and will hold other pieces of data.

Devise is used to generate the User model with certain attributes for the purposes of authentication. Authenticatable - stores passwords to ensure that details are correct on login. Recoverable - Allows users to reset passwords. Registerable - Allows users to sign up. Rememberable - Manages session tokens so that users will be remembered when returning to the site. Validateable - Validates that fields will be stored correctly.

A User can have many Tools that they own and wish to rent out. The ability to create and manage tools is restricted to a User with the role of ‘Owner’. This relationship specifies that a User does not need to have Tools (they may just be looking to rent tools). However, if they do have tools to rent out, they can have many tools associated in the model.

Users also have the ability to rent out many different tools from other users. They do not need to have rentals, as they may be inactive within the application if they have no projects to complete, and thus no need to rent any tools.

Used as an easy way to keep track of the tools that a user has, is, or will be renting. It assigns a rented tool to a user by referencing the tool through the rental model. Although the relationship is similar to the has_many :tools relationship, this is distinct in that it tracks and associates a different type of (ie: rented, not owned) tool.

Note that this relationship is represented differently within the ERD. Because the relationship is only specified for ease of information access the application, and not actually required at all.

As outlined above, the ability create and manage tools is restricted to a User with the role of ‘Owner’. Although the distinction between an ‘Owner’ and a ‘Renter’ is only used to improve user experience as part of the MVP, the requirements and details required for signing up as either an ‘Owner’ or a ‘Renter’ may differ in future and so was built for extensibility. Therefore, a user can have many roles, while each role can also contain many users.

On top of this, an ‘Admin’ role exists that allows the management of all listings on the site.

Roles are created and assigned using Rolify. Users and their roles are stored in a join table generated by Rolify called UsersRoles.

Each and every tool must have an associated user to be able to be created, and thus a Tool belongs to a User. Without a user to reference, the tool would not have details for where or how to rent the tool.

Although a Tool obviously can’t be rented out by multiple people at the same time, future, past and current rentals can all apply to a single tool. As such, Tools can have many Rentals. Additionally, a tool does not necessarily need a rental to exist.

A tool can fall under a wide range of different categories, but categories can also contain a wide range of different tools! As such, tools have and belong to many different categories. Using a CategoriesTools join table, tools, their categories and vice versa can be tracked.

Much like a user can have rented many tools, a tool will also keep track of the users that have rented the tool by referencing those users through the rental model.

Note that this relationship is represented differently within the ERD. Because the relationship is only specified for ease of information access the application, and not actually required at all.

A rental must reference a tool, otherwise there is no way of knowing what the rental refers to at all. Therefore, each rental must belong to a tool.

A rental must also reference the user that is renting the tool (Note - this is different to the tool owner!). Without someone paying money to rent the tool, there is no rental. As such, a rental must belong to a user.

As discussed in the tool model section, a tool can fall under a wide range of different categories, but categories can also contain a wide range of different tools! As such, categories have and belong to many different tools. Using a CategoriesTools join table, categories, their tools and vice versa can be tracked.

Users can be assigned different roles which will determine what they can see and do within the application. Roles can also have many different users. Although this functionality is not utilised as part of the MVP, it was included for easy extensibility in the future.

Roles are created and assigned using Rolify. Users and their roles are stored in a join table generated by Rolify called UsersRoles.

Before any work was undertaken, a thorough review and analysis of the project requirements and rubric was undertaken. Each task and requirement was written down and stored in a markdown file. From here, a number of notes were made about each requirement to more clearly define what was needed to fulfil the requirement.

After completing this list of needs, brainstorming was conducted to design a platform which would solve all of the items in the list. Mates Rates, a tool rental platform was decided upon as a way to satisfy all criteria and solve a real world problem.

Once the idea was solidified, the rest of the initial planning was done. Given the relatively large scope of the project given the timeframe, a rigorous plan needed to be implemented in order to ensure deadlines and goals would be met and the project would stay on track.

It was decided that the project would be broken down into sprints.

A sprint is a short, time-boxed period when a scrum team works to complete a set amount of work. Atlassian Agile Coach - Sprints

By breaking the project down using sprints, the project became much more manageable. Rather than jump from goal to goal and task to task constantly, focusing intensely on a certain problem for a relatively short amount of time would allow for a far more streamlined, less disruptive process.

If everything goes according to plan, goals will be kicked regularly and progress will be constant., following along with Agile principles. Atlassian - Agile ManifestoHowever, if something goes wrong, the next sprint can be adjusted to cater to the new problem. This would essentially be combining the sprint retrospective and the new sprint planning all rolled together.

Although the project does not involve working as a team, following along with Agile concepts and using sprints proved extremely useful for project management by allowing the development process to remain fluid.

As a part of sprints, stand up meetings are typical to help with any blocks or challenges that might have arisen in the current sprint by sharing with the team. As outlined above, there was no team for this project. However, as part of learning in Coder Academy’s collaborative environment, the developers held daily morning stand up meetings to help each other with these problems. That way, if someone had previously solved the problem that a certain developer was having, they could help quickly solve the problem in order to remove the block and then continue with making progress.

In order to set clear goals for sprints and turn the application into something achievable, user stories were generated for Mates Rates.

Each application feature and user interaction with the feature was planned and mapped to a user story. On top of actually providing a goal for sprints, creating user stories helped form a foundational idea for how to achieve certain goals using code.

The user stories would form the foundation of the goals that needed to be achieved in each sprint, with each story having a list of tasks associated with it that would need to be completed in order to fulfil that story.

Github Projects was used as a project management tool in order to track user stories and sprints. Github Projects is a kanban style scheduling system that allocates tasks (In this case - user stories), represented by cards on the board, into columns indicating what stage of development each task is in. For example, it is common to have ‘To do’, ‘In Progress’ and ‘Done’ columns which a card will move through as tasks are checked off.

Github Projects was chosen for the direct association and linking capabilities it has with Github itself, which was used as a remote source code repository for version control.

Screenshots of the initial setup for the Github Projects kanban board, including documentation and user stories.

Based on this initial setup, a number of rough goals were laid out and mapped to dates, which were to form the foundation for the project sprints.

These sprints were designed to be extremely flexible - without a wealth of experience to draw on it is difficult to provide time estimates. As discussed above, the sprints were designed more so for the goals and direction that they would provide. Having said that, the periods of time were still important to observe as they were balanced well for sprint retrospectives throughout the project.

The initial design for the project sprints are as follows:

1. Sprint 1 - Initial Documentation and Project Set-up

Monday 28/10

Sprint 1 Screenshots

Projects Cards

User Stories

Documentation Cards

• Map Rubric to tasks
• Brainstorm Idea
• Plan Project
  • Design Sprints
  • Record User Stories
  • Set up Github Projects
• Research and Plan Documentation

2. Sprint 2 - Database Research, Design and Documentation

Tuesday 29/10

Sprint 2 Screenshots

• Application Design
  • Purpose
  • Description
  • Tech Stack
    • Third Party Services
  • Features
• Database
  • Design Models
  • ERD
  • Active Record Associations Documentation
  • Database Relations Documentations

3. Sprint 3 - Application Design and Wireframing

Wednesday 30/10

Sprint 3 Screenshots

Sketches

Designs
Home

Rentals

Tools

Browse

Sign Up

User Dashboard

• Wireframe Sketching
  • Pages
    • Home Page
    • Sign Up Page
    • Sign In Page
    • User Dashboard
      • Owner Dashboard
        • Upcoming Rentals
    • Current Rentals
      • Renter Dashboard
    • Upcoming Rentals
      • Current Rentals
      • Edit Account
      • Rental History
        • Owner History
        • Renter History
      • Manage Items
        • Edit Item
        • New Item
    • Browse Results
      • Categories
      • Search Term
  • All
    • Item Page
    • Rental Page
    • User Page
• Design
  • Branding
  • Framework Research
    • Components Needed
    • Complexity

4. Sprint 4 - Model and Database TDD

Thursday 31/10 - Saturday 2/11

Sprint 4 Screenshots

• Rails Setup
• Gem Bundling
• Stripe Setup
• Cloudinary Setup
• RSpec Tests
• Model Generation
  • User
  • Role
  • Tool
  • Rental
  • Category
  • Image Upload via Cloudinary
• Deployment

5. Sprint 5 - Controller TDD

Sunday 3/11 - Tuesday 5/11

Sprint 5 Screenshots

• RSpec Tests
• Controller Generation
  • User
  • Tool
  • Rental
• View Generation
  • Testing Purposes, no. styling.
• Deployment

6. Sprint 6 - View TDD and Styling

Wednesday 6/11- Friday 8/11

Sprint 3 Screenshots

• CSS Framework Setup
• View Modification / Updates
  • Page Structure
  • Framework Classes
• Styling Updates
  • Framework Variable Edits
• Deployment

7. Sprint 7 - Documentation Updates

Saturday 9/11

Sprint 7 Screenshots

• Review Documentation
• Update Documentation
  • Assemble Assets
    • Wireframes
    • Screenshots
• Finalise README
  • Write New Content
  • Update Old Content

Although generally the sprints for the project were observed there were a number of things that could certainly have improved the project. Now that the application MVP has been completed it is easy to look back and see where the failures were made during the project.

Managing the scope of the project was absolutely necessary for successfully building an application that satisfied all of the requirements of the task in the given timeframe. Although the project was planned extensively, a lack of experience with Rails in general made the initial scoping very difficult. As the project progressed it became clear that the scope was too ambitious. A huge number of decisions that had been made early on in the planning process came back to haunt development as things had inevitably been forgotten. Unfortunately though, as the time had already been invested in this idea, it was too late to start over with the new knowledge. This led to significant shortcuts in the development process and cutting features in order to develop an appropriate MVP.

Most notably, where Stripe was initially a key feature, the timeframe did not allow for its implementation in the initially conceived manner. Due to the platform handling rentals instead of purchases, the payment process is different from the norm and could not utilise Stripe's simple checkout functionality. The initial plan was to have payment processed on the creation of a rental and held by Stripe until the owner has marked the tool as returned. Although this functionality exists in the app, there was not enough time to conduct research and testing into setting up Stripe to enable this process, which meant it had to be ultimately cut from the MVP.

Another big change was that Test Driven Development was not utilised. Given the scope management issues which led to time management problems and a lack of experience with RSpec, it was assumed that the delays which learning RSpec would cause outweighed the benefits of implementing it. Unfortunately, this did mean that the project suffered significantly, as it is impossible to produce code of the same quality that TDD would produce given the experience levels. Ultimately, it probably wasn't the right call to make, and other additional features should have been sacrificed before TDD was.

Screenshots of the MVP here