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.
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.
You'll have access to our team in the UK and can visit our offices at any time.
We also provide UI & UX capabilities through our trusted partner, LoneUX, based out of San Francisco.
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.
We'll create or evolve your software architecture using best practices & industry standards to optimise for secure, high-performant, resilient, and efficient infrastructure.
We'll create or evolve your software, from native applications & cloud infrastructure to augmented reality & bespoke IoT hardware.
We'll apply modern machine learning, or statistical techniques, to static problems and package the solution in software.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
We will use Travis CI to automated tests and control the release pipeline.
We will use Bugsnag for our client-side error monitoring & reporting system.
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.
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.
We anticipate the database having the following content and relationships based on the design.
.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:
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:
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.
Ratings are calculated retrospectively. To improve performance, we recalculate the ratings asynchronously.
Our approach makes use of GraphQL running on Lambda/Functions to negotiate data requests with the client app. This provides:
Improved Responsiveness
Thinner payloads
Rapid deployment
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:
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.
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:
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 |
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.
We use a proven onboarding process that allows us to engage and deploy rapidly.
Invoicing will be done on standard 30 day terms.