HackMD
Canary & Delta
Canary & Delta is a software development company whose main objective is to enable our clients to capture new value from innovative digital products. Our team of product strategists, designers and software engineers are hired to find opportunities and deliver tech that aims to disrupt and delight users.
Our team has experience co-founding tech companies, working within startups and consulting for large enterprises such as Dyson, Starbucks, Apple and Bank of America.
Team
Engineering
Our team of technologists are based in Paddington, London. We have world-class academic and commercial experience, with degrees in computer science, engineering and design from top British universities ranging from UCL to the University of Bristol.
- Mike Cooper - Data Specialist
- Ben Allen - Engineering Specialist
- Gareth Matson - Front-end developer
- Martin van der Heijden - Full-stack developer
- Mark Irvine - Full-stack developer
- Rory Smith - Technology Architect
- Nish Singh - UX Developer
- Jose Vanterpool - QA
You'll have access to our team in the UK and can visit our offices at any time.
Design
We also provide UI & UX capabilities through our trusted partner, LoneUX, based out of San Francisco.
- Andy Gilliland - Visual Design Specialist
- Kevin Gillard - Interaction Design Specialist
- Spencer Bailey - Motion Design Specialist
What do we do?
Digital Strategy
We'll create or evolve your digital strategy to align with long term business objectives, working collaboratively with your executive team to execute the roadmap.
Software Design
We'll create or evolve your software architecture using best practices & industry standards to optimise for secure, high-performant, resilient, and efficient infrastructure.
Software Development
We'll create or evolve your software, from native applications & cloud infrastructure to augmented reality & bespoke IoT hardware.
Data Science
We'll apply modern machine learning, or statistical techniques, to static problems and package the solution in software.
Technology Research
We'll critically evaluate new digital technology, showcase how it can be leveraged within your business, and outline advantages, limitations and create an implementation strategy.
How do we do it?
Our framework is inspired by lean, agile thinking. We've honed our approach over 9 years of building software for clients to maximise for end-value. We've also taken the best bits from the organisations that we've worked with at Dyson, Starbucks, Apple and Bank of America and built a framework that enables us to have the utmost efficiency.
Our Building Process
1. Project Discovery
During this research and analysis phase, we identify your organisations mission to communicate your vision through your finished product. From there, we conduct an analysis on the core minimum viable product, pinpointing key differentiators that can be leveraged throughout the project.
- Identify strengths, weaknesses, opportunities, etc.
- A clear understanding of values and mission
- Roles and responsibilities assignment
2. Plan
With a prioritised backlog in hand, we can now plan how to approach the work. Each week, we'll spend two hours clarifying the detail of each feature with you and then estimating the complexity of this work. This means that both you and the team have excellent visibility on what's coming up next, and how long it will take to build.
3. Design, Develop & Release
We work in two-week sprints, focusing on the features you have prioritised. A successful sprint is one where every item identified in this week's backlog is done. Once we've built the minimum set of features, we can go into automatic deployment mode and release as each new feature is built.
4. Follow Progress
We check ourselves against burn-down charts which map time against the amount of work we anticipated completing. This means no tunnel vision - if there's a problem, we'll solve it before the end of the day. We'll also send a concise daily email/slack message with an update on the work done that day.
5 Continuous Improvement
At the end of each sprint, the team takes time to both celebrate the successes and analyse the problems we encountered. We look to take at least one action each week to make us faster for the next, increasing velocity week on week to deliver value to you, and your users, in lightning time.
Quote: REDACTED
CMS - Sanity.io
We explored Sanity.io and other CMS tools (Strapi) as an option to get REDACTED underway. However, we felt that these options would limit control over the infrastructure layer and, as such, wouldn't provide the capabilities required without compromising future growth/scalability.
We, therefore, suggest a bespoke implementation.
Frontend
The client application will be built using the ReactJS framework in TypeScript. We'll follow the standard REDUX architecture for implementing visual state. The development will involve building a library of reusable widgets which can be shared across web, mobile and the admin console.
The frontend development strategy will take a feature by feature approach where we will release functional sections of the website as soon as they've been developed, rather than connecting the view and data layer near project end.
Apollo & GraphQL
To provide an interactive and responsive interface in quick turnaround time, we'll make use of Apollo Client with React. In this scenario, frontend components declare their data requirements; by combining Apollo with GraphQL, we're able to provide that data with strong end-to-end typing, which reduces data integrity issues and increases productivity. The Apollo Client provides all the underlying fetch, cache, and modification of application data.
In addition, Apollo is an excellent fit with microservice architectures and modern UI frameworks like React. It serves as an abstraction layer that decouples services and apps so that each can be developed independently of the other, in any language and on any platform.
Adding a data graph layer to the stack lets us build new features in a fraction of the time. We are no longer responsible for maintaining HTTP boilerplate code, can move fast without waiting on backend teams, and more easily keep features consistent across web and mobile platforms.
Workflow
Our team uses gitflow to help simplify feature development at scale. Additionally, our senior developers lead code reviews for each new feature which enforces quality and consistency across the project.
Testing
For testing, we use Jest, a JavaScript testing framework, designed to ensure the correctness of any JavaScript codebase. We find the most valuable tests are ones which target specific data & controller logic, for example, adding an item to a Wishlist. As such, these are what we will be applying to this project.
Beta & Production
We will create two application environments, beta and production. The two environments will have an identical infrastructure setup, and beta will contain a scheduled copy of the production database.
Continuous Integration
We will use Travis CI to automated tests and control the release pipeline.
Error Monitoring
We will use Bugsnag for our client-side error monitoring & reporting system.
Backend
Our approach involves splitting the backend into two distinct pillars: .NET Microservices (A) and a NodeJS GraphQL Apollo Server (B).
This allows us to use the strengths of each technology; A .NET microservices will allow us to achieve advanced functionality like image & data manipulation and GraphQL will allow us to achieve a highly responsive and performant client application.
Infrastrcture
The backend can be deployed across all 3 main vendors (Azure, AWS & GCP) so you can benefit from the cost savings available on all platforms and avoid vendor lock-in.
The platform will make use of vendors' microservice products (AWS lambda, Azure/GCP Functions) to achieve low costs and ensure it is highly scalable.
This service is database agonistic - any SQL service will suffice.
Data
We anticipate the database having the following content and relationships based on the design.
A. Microservices - .NET
.NET Microservice's provide us with the ability to offload tasks that have higher computation times and increased business logic, such as search, image manipulation, and user notifications to independent workers. We'll make use of these microservices either directly via HTTP REST requests or through Queue Services to perform operations asynchronously.
We've identified the following operations that would be best served in this way:
1. Notifications
When a "notifiable action" occurs, a request to notify the user is added to a managed queue service (SQS or Azure Queue Service etc..). The system will hook into GraphQL resolvers. This implementation enables the microservice to later issue off-platform notifications such as emails, push notifications etc. without comprising responsiveness.
The microservice makes use of a notifications table to manage the notifications the user reads. This avoids having to recompute notifications on each load.
Notifications occur when:
- You follow another user
- Another user follows you
- You follow a collection
- Another user follows your collection
- A post is approved
- A post is denied
2. Dynamic Image manipulation
To keep the application responsive, our approach is to make use of a microservice dedicated to handling image manipulation. This ensures the service can operate rapidly on different sized mobile devices.
The client app will request image sizes with a URL format which incorporates image resolution.
The resolution in the URL is calculated using the developer's intended pixel width and height multiplied by the devices pixel density. Images are cached using a CDN.
3. Rating calculations
Ratings are calculated retrospectively. To improve performance, we recalculate the ratings asynchronously.
B. Data negotiation layer
Our approach makes use of GraphQL running on Lambda/Functions to negotiate data requests with the client app. This provides:
-
Improved Responsiveness
- The frontend will be more reactive to the user's demands. This is enabled through the use of web sockets to send & receive data which avoid the overheads associated with HTTP REST requests.
-
Thinner payloads
- Optimised for mobile usage and cost. Data is not over or under fetched and only gathered as required. Coupled with their support for a variety of frontend frameworks - we think this is a win.
-
Rapid deployment
- Frontend developers don't need to wait for backend implementation. Once a query structure is agreed, everyone can get to work. Frontend developers request the information they need, the service will be backwards compatible when new data is added. This improves the speed of product improvements when integrating mobile applications.
GraphQL offers the opportunity to create a leaner backend by offloading the querying of data to the client. This reduces the need to architect, design and implements individual REST endpoints thus reducing the initial code requirements and increasing the pace of development.
GraphQL will be paired with a thin data layer, written in TypeScript to define the query types and resolvers that can be executed by the client. This layer will have an extremely limited amount of logic and serve only as a means to negotiate the clients' data requirements.
It's straightforward to add new types and fields to the API, and similarly straightforward for the client application to begin using those fields. Going forward, this helps you design, develop, and deploy features quickly.
Combined with the Apollo platform, complex considerations like caching, data normalization, and optimistic UI rendering become straightforward.
GraphQL is no silver bullet, but we think it will lend itself to responsiveness and development pace.
GraphQL in action
A large part of the REDACTED Play UI makes use of an advanced, responsive search & filtering tool.
A similar experience exists as part of Airbnb's search tool where users can apply filters to data and watch results loading in real-time. Airbnb makes use of GraphQL to achieve this, and so it would fit closely with REDACTED.
Other use cases:
- PayPal - https://medium.com/paypal-engineering/scaling-graphql-at-paypal-b5b5ac098810
- Netflix - https://netflixtechblog.com/our-learnings-from-adopting-graphql-f099de39ae5f
- The New York Times - https://open.nytimes.com/the-new-york-times-now-on-apollo-b9a78a5038c
- Nerdwallet - https://www.nerdwallet.com/blog/engineering/getting-started-with-graphql-and-apollo-part-1/
Limitations & Assumptions
Due to the short nature of the quotation phase, we have had to cut some sections of the platform due to a lack of knowledge and understanding.
We have allocated an additional 20% in the project budget for feedback and evaluational as well project minor UI adjustments.
We'd be happy to include this work in the project once we have further information.
Financials
Our estimate for task time is based on our team's feedback from the documents provided. Together, we have created a detailed estimation for the UI and data requirements for each component on the site.
Our full report of time estimations can be found here:
Costs
We estimate that our approach to the project will take a total of 236 days.
The total project cost will be £146,500 (excl. VAT).
Ongoing support after project completition will be at £650 p/d.
| Role | Price | Days Required | Total |
|---|---|---|---|
| Project Manager | £700 | 19 | £11,200 |
| Technical Architect | £700 | 37 | £25,900 |
| Senior Developer | £650 | 48 | £31,200 |
| Frontend Developer | £575 | 136 | £78,200 |
| Total | 240 | £146,500 |
Roles
Technical Architect
- Client App Setup
- Technical Architecture
- GraphQL Administration & Architecture
- CI/DevOps Work
Senior Developer
- Notifications Microservice
- Image manipulation Microservice
- Rating Microservice
- Authentication and Authorisation
- GraphQL Implementation
Frontend developer
- UI Implementation
- SEO
- Event Tracking
Timeline
We've scoped the project under the premise that we have 8 weeks. Assuming a start date of Mon 10th. The project completition date will be the 12th of Oct.
Conditions
- Consultant’s Working Day - 8 hours exclusive of travel and lunch
- Working Week - Monday to Friday excluding national holidays
- Office Hours - 9am to 5pm Monday to Friday
- Travel, mileage subsistence - Included in day rate within M25. Payable at standard T&S rates.
- Professional Indemnity Insurance - included in day rate
Processes and Legals
We use a proven onboarding process that allows us to engage and deploy rapidly.
Invoicing will be done on standard 30 day terms.
