Frosty is a Email Outreach tool I build for my former marketing Agency, S2 Digital.
We had a big problem. The available SaaS on the market for email outreach didn't fit our needs. They were either loaded with lot's of features we didn't need (and they charged a premium for it). Or, they removed features we did need. As a result, our sales process continued to change. And thus, remained inconsistent.
For that reason, I built Frosty for consistency and ownership of the outreach process.
The second reason I build Frosty was because of email deliverability. Deliverability is never taken into account with SaaS (in 2018).
There is a fine line between email outreach and spam email. Our agencies' reputation and our email sending accounts must remain credible. Thus, we took the view that "how" we send emails was important.
We built these deliverability ideas into Frosty.
Yes, and no.
The production version of Frosty was went live in March 2018. And we used to to generate over $500,000 in revenue between 2018 - 2022.
Sadly, the impact of Covid destroyed the business. Because most of our clients were local businesses. Most of which, closed their doors during Covid. The production version is still in use (maybe?) by it's new owners.
This project is a recreation of the Domain Layer from the original 2018 version. Which means all the improvements made after 2018 have been ignored. Because they are business secrets.
It's a portfolio project that shows how I:
- Work on projects
- How I create domain entities
- How I create domain Value Objects
- How I make software decisions
- How I write unit tests
- And how I refactor unit tests
- How I plan ahead for Application services
The production version of Frosty (written in TypeScript MVC) lived on the company services. It was not a publicly available software. We built it around our own sales system, and that of our clients.
Here is what it looks like (2019 version):
This project only contains the Domain Layer. If read, you may infer some of the application services. It's worth making it explicit how I intend to deal with it.
The application layer will use MediatR to create the CQRS pattern. There will be queries, query handlers, commands, and command handlers. Each query and command will live in a use-case specific folder.
For example GetRecordQuery is a query that will be in the Frosty.Application.Record.GetRecord namespace and folder. Equally, the command AddToSalesPipelineCommand will be in Frosty.Application.Record.AddToPipeline namespace and folder.
These folders will have the query/command and their respective handler.
Having a long list of use-case based folders makes it very easy to find, edit and extend specific features.
These two documents are available on request:
- Domain Planning Documentation: A first look into the domain, the entities and how they fit together.
- Functional Specification: A first look at the usecases.