1

“DevFlows, a productivity tool for developers”

Andrew Paulino, Brandon McCarthy-Santos

California State University Monterey Bay

CST499: Capstone Planning Project

Mentor: David Wisneski

Prof. Bude Su, Prof. Brian Robertson, Prof. Cassandra Eccles

May 15, 2023

 2

Executive Summary

Professional developers work through many different issues and items in their day to day.

Some of these items may be as simple as fixing a bug, while others may be reviewing another

developer's pull request. Through personal testimony we found that there is no tool on the market

that is tailored for the developer workflow experience. We aim to solve that goal with DevFlows.

We have gathered pain points of the everyday developer and we are planning on solving them by

targeting three main features. These three features are a pull request management system to help

developers manage their pull request and the pull request from the team, a developer web tooling

suite; which encourages the developer to utilize things such as URL modifications and inline

styles, and finally we want to also add a note taking feature which will help the developer gather

notes for their workplace. These three features will hopefully help the developer gather niche

workplace workflows in one central location. The problem we observed is that developers tend

to use a lot of notepads and several runbooks for very basic tasks. We want to change that by

offering an all in one solution.

We will be utilizing chrome / firefox extensions to get us as close to the workplace of the

developer as possible. We will also include a sign up flow on a website hosted by DevFlows to

sign up team members. Overall DevFlows is here for the developer and for the developer. We

will be gaining insight from the developer to understand the concepts and needs and implement

that in DevFlows.
 3

Contents

Introduction......................................................................................................................................4
Environmental Scan......................................................................................................................... 4
Stakeholders.....................................................................................................................................5
Ethical Considerations..................................................................................................................... 6
Legal Considerations....................................................................................................................... 6
Project Goals and Objectives........................................................................................................... 6
Goals.................................................................................................................................... 6
Objectives............................................................................................................................ 7
Final Deliverables............................................................................................................................ 7
Approach/Methodology................................................................................................................... 7
Timeline/Resources..........................................................................................................................8
Milestones........................................................................................................................................ 9
Resources Needed..........................................................................................................................10
Platform..........................................................................................................................................10
Risk & Dependencies.....................................................................................................................11
Testing Plan....................................................................................................................................12
Team Members...............................................................................................................................13
References......................................................................................................................................14
Appendix........................................................................................................................................15
 4

Introduction

DevFlows is aiming to address the issue of productivity in the professional workplace as

a developer. Through research and personal testimony, we have noticed there is a gap in the

availability of productivity tools tailored to developers. The problem is that most tools available

on the market are targeted towards the workflow of product managers - not for developers, this

presented us with the opportunity to build a tool for full-stack / front-end developers that target

specific niche features. DevFlows is a specialized developer management tool tailored

specifically for developers, offering comprehensive pull request tracking, web tool integration,

and a link tree management system. Unlike notion, which is a more general-purpose project

management collaboration platform, DevFlows focuses on providing targeted features that

enhance developer workflows and streamlines code collaboration processes.

The client for DevFlows is the working developer who needs to keep tracking of their

projects and workflows in one centralized platform, alleviating the headache of sorting through a

million notepads on their desktop, or reaching out to their co-workers regarding the pull request

status.

Environmental Scan

As far as competitors for our project DevFlows, after surveying the market for competing

products and inquiring with our peers that utilize productivity software, we discovered that the

product which is the most similar to our pitch is one called Notion. “Notion is a single space

where you can think, write, and plan. Capture thoughts, manage projects, or even run an entire

company — and do it exactly the way you want.” (Notion, n.d.) After exploring this tool, our

analysis is that it strives to be an all-in-one productivity suite that is not catering specifically to

the developer niche, thus creating an opportunity for DevFlows to fill that need with a
 5

specialized integration to github or other tools that are commonly utilized by developers. We

would say that this plugin is not competing with Notion as they serve separate purposes that

could be utilized in complementary ways with our product.

Stakeholders

For this project, the stakeholders are ultimately the end-user developer, we are primarily

targeting front-end / full-stack developers. They gain the most by the project’s success in the

regards of getting an internal tool to help manage their productivity and workspace knowledge.

By having access to this information readily in the browsers developers should be able to

improve productivity of non-technical related tasks. In addition we the creator-developers

working on this project could be considered stakeholders as we have a vested interest in the

success of the project.

Ethical Considerations

For this project, an ethical consideration we are making is around user privacy and

accessibility. For privacy we plan on utilizing third-party log in systems to ensure no data is held

within our services relating to email and password or sensitive information. Other considerations

are to ensure our data is held based on the user preferences - if the user plans on only holding

data locally we will give them this option. Ethically we are also ensuring that our web platforms

remain under the WCAG 3.0 standards to ensure we follow accessibility standards and laws and

make this platform accessible to all.

 6

Legal Considerations

Our main legal considerations are making sure that we securely handle data and making

sure our permission system verifies who accesses the data and if it belongs to them. Other legal

considerations we are making is around accessibility for our front-end UI, and ensuring we hold

up to WCAG 3.0 (WCAG 3.0) standards. Another consideration we are also making is

localization for this application, as it stands we plan to serve only English speaking users for

language support - due to resource constraints and targeting around US Laws.

Project Goals and Objectives

As part of this project, we have several goals and objectives. In this section we will detail

our goals and objectives and list what steps are needed to achieve them. We have two primary

goals that act as major pillars for our project.

Goals

Our first goal for this project is to be the top ten developer productivity tool on the

chrome / firefox extension store. Our second goal is to get at least 10 developers using this tool

in their workflow. Our first goal is bold, but we believe that we can capture this market space in

the extension store and be the tool people think of when they need an extension to help them

develop better as a full-stack developer. Our second goal is more specific, but just as important.

We want to make sure people are actually using our extension and there is a need, even though

the number is small - we want to set expectations and also ensure our stakeholders can use this

extension in the end.

 7

Objectives

For objectives, to reach our goals we are aiming our objectives to be relatively simple.

The first one is to get our extension(s) to the extension stores after development is complete. The

second objective is to reach out to developers across several companies and offer a beta of the

extension - and potentially offering teams of developers the ability to sign up as a team. To

accomplish these objectives we are going to need to develop an extensive platform to support

these features. In the next section we will discuss deliverables for the project.

Final Deliverables

For final deliverables, we are targeting to release two extensions one chrome extension

and one firefox extension. If we do not have enough resources or time to get both we are

ensuring we will release the chrome extension at least. We will also be delivering a client web

application which will serve as a login and registration portal for the extension. We would like to

separate this from the extension code and keep the logic in the web application for registration.

All of our backend services will be hosted in AWS and will not interact with the user directly, but

instead will be consumed by our client GUIs.

Approach/Methodology

We intend to utilize Trello, employing a mix of Kanban methodology and Agile. Our

objective is to create tickets and organize our work into milestones for the project. With each

milestone, our aim is to achieve a partial deliverable, ensuring steady and continuous progress.

We are targeting almost a sprint based system in terms of timing and plan on sizing tickets for

smaller tasks and goals alike. We will be utilizing a scale of 1, 2, 3 in terms of sizing. 1 being a

small task that can be done within a day, 2 being a medium sized task that can be done in 1-2

days, and 3 being a large task that will take 3+ days to complete.
 8

Timeline/Resources

I. Detailed Timeline

Date Stage Deliverable

06/12/2023 1 ● UI Mockups
○ By this milestone we should have
all mockups in Figma done and
ready to consume by the front-end
● Repo setup
○ By this milestone we should have
all the repos setup to push new
code into them. This includes
front-end and back-end repos
● Trello Setup
○ By this milestone we should have
trello tickets setup and sizing
determined
● Database Schema
○ By this milestone we should have
our database schema setup for our
registration system, pull request
system, and our runbook / dev
tool system.

06/26/2023 2 ● Registration System

○ By this milestone we should have
our registration backend setup and
our registration frontend setup.
We will utilize logging in from
github only.
● Login system
○ By this milestone we should have
our login system setup and
backend system setup.

07/10/2023 3 ● Pull Request System

○ Pull request system will be built
in this milestone. The deliverable
will be the ability to submit a pull
request to the daily thread and the
ability for another developer in
the team to see the pull request in
the thread. (Frontend + Backend)
 9

07/17/2023 4 ● Runbook System

○ The runbook / note taking system
will be built in this milestone.
You should be able to store links
in an organized way to guides or
repos.

07/24/2023 5 ● Dev tool System

○ In this milestone we will build the
dev tool system for our custom
API features. We will build items
such as query editors, advanced
dev tool editors on top of the
normal dev tools, and query
normalizers for URL flags.

07/26/2023 6 ● QA Bug Bash

○ In this milestone, Andrew and
Brandon will conduct a bug bash
and test out all the individual
flows.
● Release
○ In this milestone, we will release
the extension to the chrome /
firefox extension store.

08/09/2023 7 ● Final Release + Demo + Fixes

○ This stage represents the capstone
festival and any last minute bug
fixes or changes.

II. Milestones

For our milestones, we will be combining the planning and user management features as

milestone one. We will then coordinate each feature as an individual milestone, in this case the

pull request feature will be milestone two, notebook / runbook feature will be milestone three,

and dev tools will be milestone four. Our final milestone will be a combination of stage six and

seven. Our final milestone will coordinate with our final deliverable and demo at the capstone

festival.
 10

III. Resources Needed

Our resources will consist of AWS as our backend provider and frontend provider for

hosting, github as our source control, and finally we will be using personal computers for

development.

Platform

For the platform we will be utilizing AWS as our main hosting provider for our backend

and frontend infrastructure. We picked AWS for several reasons, the pay as you go model is very

good for us as that ensures we will not be paying extra fees unnecessarily. AWS also has its own

ecosystem of services which makes it very strategic to use, for example if I am using a database

in AWS we can connect that with our API securely and easily since the platform supports

cross-service support. We will also be using github to house all of our code for both services and

ensure that we are using source control to make sure that our development process is not slowed

down by needing to copy and paste source code.

For our frontend, we will be using React.js with a combination of the Chrome / Firefox

extension API. React.js is a very good and solid platform to use for several reasons. Community

support is excellent due to the fact that it has been around for a while, it is good for beginners to

orient themselves in, and the performance for web is very good since React.js uses a virtual

DOM for state updates to the HTML document. As well as all of these infrastructure pieces, we

plan on automating our deployment of our application by having a release cycle every milestone

to ensure that our code and demo is up to date.

 11

Risk & Dependencies

One of the risks associated with our project is that a browser update could invalidate a

portion of the API that our code utilizes, relegating it to older versions. Because we are aiming to

utilize two browsers to deliver our code, another roadblock we might encounter is that a feature

supported in one of the browsers API’s is not compatible with the other browser. This would

force us to derive creative solutions as the problems unfold. Another risk is one of our features

taking longer to implement than we thought and taking up more time than allocated. For

example, the pull request feature we intend to implement has a scope that is higher than the other

two and therefore we may have to realign our target timeline to ensure delivery. Should this

feature scope become exorbitant we may have to recalibrate our deliverables entirely and focus

on this feature alone or to suspend this feature and work on the other two.

The dependencies of our project will have many moving parts. We intend to utilize

Javascript and Node.js which are very robust and therefore we don’t anticipate running into any

depreciations in the course of our project. Due to the fact that we are utilizing a database we will

need to determine the most appropriate implementation that will interface correctly for our

needs. We will have to wait until the database schema is set in stone before making meaningful

progress on the back-end. For our front end we can prototype the layout before coding, and this

should be a first step to ensure that both applications have a coherent feel and style that are

synonymous.
 12

Testing Plan

For testing plans, we plan on utilizing several different tools. One of the tools we will be

using is AXE dev tools, which is an accessibility tool to help test and ensure you meet W3C

guidelines (Deque, n.d.). Another tool we will be using is google spreadsheet to keep track of

any bugs we find while manually testing our work. We also plan on utilizing unit tests and

integration testing to ensure our frontend is up to standards. On top of our own bug bash, we plan

on also utilizing a beta testing group of developers who we are in contact with around this

program, we will provide them with a beta version of our application and a feedback form for

any bugs or suggestions. We plan on utilizing Jest and Cypress for this task, as they are industry

leaders in frontend testing. On our final milestone, we will conduct a bug bush with ourselves

and go through all the flows of our application, testing from registration to our runbook feature.
 13

Team Members

Andrew Paulino

● Team Lead / Full-Stack Developer

As team lead, my role is orchestrating the development processes and expectations of the project

as a whole. I will also be undertaking the responsibility of the frontend services, such as the

extension and web application for registration. I will also be helping onboard Brandon into these

new technologies.

Brandon Mccarthy-Santos

● Full-Stack Developer

As a developer I will be responsible for helping Andrew build out the back-end and database

schema as well as assisting Andrew in prototyping the interface UI. Once that portion of the

project is completed I will focus my energies on building out the appropriate API endpoints

required by the available services and taking on any additional troubleshooting responsibilities as

they develop.
 14

REFERENCES

Notion. (n.d.). What is Notion? Notion. Retrieved from

https://www.notion.so/help/guides/what-is-notion

Spellman, J., Montgomery, R. B., Lauriat, S., & Cooper, M. (Eds.). (2021, December 7). W3C

Accessibility Guidelines (WCAG) 3.0. W3C. https://www.w3.org/TR/wcag-3.0/

Deque. (n.d.). Axe Devtools: Developer tools for accessibility testing. Retrieved from

https://www.deque.com/axe/devtools/
 15

APPENDIX