diff --git a/WRITEUP.md b/WRITEUP.md
new file mode 100644
index 0000000..4a1f40a
--- /dev/null
+++ b/WRITEUP.md
@@ -0,0 +1,144 @@
+# Please contribute! Reword, delete, add, anything
+
+## Team Communication
+Weekly development check-ins are held on Tuesdays at 8 pm EST. The team uses Google Meet, which is more cost-effective (free). The team also uses Slack for daily communication. For all documents the team relies on the [qg-docs GitHub repository](https://github.com/QueerGlobal/qg-docs) unless individual Google Docs files are utilized. All sources are pinned to the relative Slack channel.
+
+### Communication Between Engineers - The Communication "Culture"
+Once topic-specific channels were created the conversations became free-flowing. 
+
+The #development channel is the hub where all ideas reach everyone the fastest.
+
+For all frontend-oriented work there are the QG GitHub account's [issues](https://github.com/QueerGlobal/qg-frontend-v2/issues) and [pull requests](https://github.com/QueerGlobal/qg-frontend-v2/pulls) opportunities to discuss code-specific details.
+
+Note: Initially there were no standards in place for things like how to write pull request comments, code formatting and style, and how to distribute work to new team members, regardless of their experience level. We all had to work together through situations usually laid out ahead of time by management for an established entity. We became our own AND each other’s “Manager”. The end result is our current culture: Where own standards for how to work together are accepted while at the same time being courageously open to and ready for inevitable needed changes. There is an acceptance of our autonomy through trust.
+
+### Communication with Interested/New Volunteers
+Deacon is the QG Co-Founder and is ever-present to greet one and all. In all Slack channels, Deacon is the one who will direct volunteers to the QG family. 
+
+Once team members join the QG Slack, and Deacon announces them, they have access to the full family and is welcome to take initiative in introducing themselves in 1:1 conversations and in the general Slack channels.
+
+Our project relies on individuals who tend to be self-starters; those who are comfortable with taking initiative on the Roadmap tickets as well as seeing the valuable app areas in need of building out first compared to other areas. This is a good thing because it means that the team is not bogged down with the need to micromanage. 
+
+## Product-Oriented Process
+### The “Defined Problem”
+Need for a new, modern, web application with immediate resources for networking with professionals, knowing the latest events, and building community for LGBTQIAA+ people, by LGBTQIAA+ people.
+
+### The “Solution”
+Create a web application that serves as this source/product. A web application, vs a website, because it will be interactive and have a database that stores relevant resource data.
+
+### Methodology
+Agile? Scrum? Waterfall? TBD
+
+A series of Roadmap boards are used for task distribution, broken up into “tickets”:
+[Frontend Roadmap](https://github.com/orgs/QueerGlobal/projects/1)
+[Infrastructure Roadmap](https://github.com/orgs/QueerGlobal/projects/3)
+[QueerGlobal Development Onboarding Documentation](https://github.com/orgs/QueerGlobal/projects/2/views/1)
+
+### Targeting User Needs
+From surveys and informational interviews?
+
+From UX interviews?
+
+Research?
+
+### Design
+A traditional web application structure of main pages as well as unique features such as sharing artworks.
+
+### Model
+Wireframes, mockups, prototypes, etc. TBD
+
+### Application Architecture Overview
+List of minimum requirements for local development
+- Golang TBD
+- Node JS LTS (as of June 2023) version
+- NPM version TBD
+- MySQL version TBD
+- ESLint Extension
+- Golang CI/CS Lint
+- Precommit, a language-specific commit checker
+- Etc. TBD
+
+Create-React-App, Node JS?, MySQL?. 
+Handling stale API data? 
+Pull request reviews consist of engineers across the team zeroing in on all aspects of each other's code.
+
+[Golang](https://go.dev/)
+[MySQL](https://dev.mysql.com/)
+[React](https://reactjs.org/)
+[Create-React-App boilerplate](https://create-react-app.dev/)
+Dedicated GH repo for client front-end app
+Dedicated GH repos for microservices
+
+Logging - Management Tool
+Client (FE): TBD
+Database: TBD
+Server (BE): TBD
+API rates, stagnant data, observation?
+Network: TBD
+
+Version Control - Git; Repositories housed on GitHub
+
+As of June of 2023, every engineer can access, review, approve, and/or block a pull request
+
+Pull request template and labels created by team and are currently being formalized [in this document](https://docs.google.com/document/d/1prQ08FbkMTHAMC2-BvpEeLSk3_YoRl18owza9_t3xJY/edit?pli=1)
+
+### Testing
+A demo-repository is being planned for a staging version of the app. Here is [a spreadsheet of details](https://docs.google.com/spreadsheets/d/1xlDfIMQn_NXb4PbE8QkncdGxw6H-h9RGGHn8_45z5r4/edit#gid=584784234) for future group testing
+
+Unit, automated, QA, user, performance - TBD
+
+To be used: [Accessibility Conformance Report, 2018](https://www.fdic.gov/about/doing-business/acquisition/acr.pdf) - Information Technology Industry Council
+
+Testing risks? Taking more than expected time? What do do with faulty tests; TBD
+
+If signup, login, and/or payments tests are not working, this is a level 1 severity. Take the site down immediately.
+
+### Documentation
+A GitHub repository of documents, future Wiki, TBD. 
+
+Will cover requirements for product functionality, what went into the designs, architecture decision making, testing, group process, etc.
+
+Changelog? TBD
+
+Database relations broken down in [this document](https://docs.google.com/document/d/1rt0V8w4bygqfRPnhwbbE9FCcKIAJI2yT1as8AMG_ehA/edit#heading=h.yfunt0g4gpy6)
+
+### Deployment
+AWS? 
+
+Other cloud environment?
+
+A/B testing? SEO? TBD
+
+If signup, login, and/or payments are not working, then the app is not working. Take the site down immediately.
+
+### Measurements/analysis
+Quality metrics, API connection rates, user feedback, TBD. Analytics is critical for the effectiveness of the product.
+
+Example of measurement performance, from the open-source tool [Lighthouse Chrome DevTools report on performance metrics](https://developers.google.com/web/tools/lighthouse#devtools)
+- Install Chrome
+- Open Chrome DevTools
+- Select the Lighthouse panel
+- Hit "Generate report"
+
+Lighthouse Node module - For local report generation
+
+For testing web pages in production
+
+If signup, login, and/or payments are not working, then the app is not working. Take the site down immediately.
+
+### Maintenance
+Bug-tracking procedures; TBD
+
+If signup, login, and/or payments are not working, then the app is not working. Take the site down immediately.
+
+### Educating the user
+FAQs, video tuts, video interviews, TBD
+
+## Mobile Development
+Probably not but TBD
+
+## Marketing and Promotion
+TBD
+
+References:
+[IEEE 829 Test Plan Example, Ecommerce Website Cross Browser Testing Test Plan](https://docs.google.com/document/d/1F1TUX5BkviRbw8auI2Xq2K2wyGTS-Ag14DRymiELmzc/edit)
\ No newline at end of file