---
title: AAR for DAOSquare
---

# After-Action Review for DAO Square

## 0. Background
### Raid Party
1. Cleric: Brandon1; Taekikz
2. Monk: arentweall (Amos)
3. Wizard: dekanbro; Keating

### Client background
DAOsquare has previously engaged DAOhaus to build a Community Contribution Opportunity that would help fund-raise for DAOsquare. From an initial look, DAOhaus modified the current Moloch & DAOhaus functionality to enable it [here](https://app.daohaus.club/dao/0x64/0x815aa1d90bcf6535bba894db67c49cd34f5cfc66/cco)

There were some issues that they didn't like, namely:
1. Frontend bug on launch day
2. Funds locked when not claimed by users

Due to this DAOhaus experience, DAOsquare was hostile and defensive before even engaging with Raid Guild. They expected excessive protections and attention from Guild members, in part to compensate for their experience with DAOhaus although Raid Guild is separate. DAOsquare was behind on schedule and had community members to appease to.

Moving forward, they wanted to **build their next project (aka Incubator), which helps facilitate community-based investment and incubation of Web3 projects**. They were looking to engage Raid Guild to build it.

## 1. What was supposed to happen?

Given that there was some previous work by DAOhaus, the client would like Raid Guild to:
1. **Investigate how much previous work can be re-used** to scope the Incubator project.
2. **Scope the Incubator project**
3. If 1 & 2 is done, **build** the Incubator project.

After Brandon1's first meeting with them, he assembled the Raid Party and this was the initial ballpark figure proposed to the client.
| Phase | Objective | Timeline | Estimated Cost |
| ----- | ------------------------------------ | --------------------- | -------------- |
| 1 | Investigation & scoping of Incubator | 1 month | $25K |
| 2 | Actual building of Incubator | TBD (est. 3-6 months) | $40K / month retainer |

## 2. What happened?

After the initial proposal, the Raid Party had another call with the client to better understand their scope and requirements. During this call,
* Client explained their preferred approach for the project (i.e. 3 phases, with each phase resulting in a release of some product to their community)
* Client requested for 'co-working window' for Raid Party and client to have clearer communications
* Client requested for speeding up of investigation and scoping timelines.
* Raid Party proposed above pricing and client would get back

After the above call, the client raised objections about the price and quote. Brandon1 responded and managed to get their buy in to continue the process.

The client arranged for another call with the Raid Party, attaching a list of 'demands'. Due to technical difficulties on the Client's side, not much was discussed and the discussion of terms would be done asynchronously. Please see the [demands here](https://docs.google.com/document/d/1Rhuu8_LPLMuHYRha-JPMtKeLnrJQFsLV0TFs0H5EzJs/edit).

Many of the demands are unconventional, such as requesting for a 2-hour response time during the 1-hour daily Office Hours, open-ended liability for Raid Party to fix bugs, deposit of only 10% of funds for the project, etc.

After discussion, the Raid Party counter-proposed the terms along with a higher quote of $40K for scoping, $55K for building, in exchange for more time and effort to comply with DAOsquare terms.

After a week, the Client came back, saying that they took a vote as a DAO and will not proceed further.

Raid Guild engaged Dao Square in 4 meetings over 7 weeks, and was unable to secure a scope worth $185-240k.

## 3. What did we learn for next time?

1. **Identify Client Red Flags Early**

A client having red flags is fine, but it's important to 1. ensure we're not wasting efforts, 2. build in budget/schedule for additional risk, 3. be willing to walk away from a bad client.

DAOsquare red flags included:
- Hostile during the initial consultation // had recently been burned
- Demanding/unhappy DAO community they answer to
- Large timezone difference and some language barrier
- Lack of scope clarity and lack of urgency to achieve scope clarity. Rejected generous pricing terms for scoping
- Requesting further consultations that don't meaningfully progress the engagement
- Demands of vaguely written practices/contractual terms outside Raid Guild development norms. The vagueness posed a risk of non-payment to Raid Guild

In future, it will be a better use of resources to either filter these clients out via high pricing or saying we are busy, or request an upfront consultation deposit.

2. **Manage Timezones, Language Barriers, and DAO Communities.**

DAOsquare was a logistically difficult client being located in China, and having a mostly mandarin speaking team. Coordination and communication was going to be a continual challenge throughout the engagement. There were also cultural barriers/expectations.

One big challenge during negotiations was that **much of the tone and emphasis of important points was lost in translation** as William (DAOsquare) paraphrased Brandon's messages to his team and the entire DAO community. Brandon speculates William could have unintentionally overemphasised risks and underemphasized value communicated. This is difficult even without a language barrier, but was made worse due to it. In future if the decision maker is a DAO community, Brandon's recommendation is to communicate important points in public channels rather than DMs to avoid miscommunication.

3. **Communicate Early the Importance of Scope Clarity**

This is a reoccuring problem for many clients. Much of contentiousness was due to **both sides wanting protection from unknown future surprises**, and wanting to reduce risk. Had there been an early push for an airtight scope or scoping process, both sides would have been more comfortable with the terms of the engagement moving forward.

**Next Step**: During the initial consultation, it's a good idea to express that getting to a clear scope is the first goal for both sides. We should also set a timeline to firm up scoping (e.g. 2 weeks) to prevent unnecessary expense of Raid Party's time and effort.

4. **More Clarity on Contractual Terms**

This should be an ongoing discussion as we can expect some future clients to request contractual terms related to withholding of payment, bug fixing, quality standards, change orders, disputes etc. There are good terms (eliminates vagueness), and bad terms (introduce risk/vagueness). DAOsquare's terms were mostly bad, and clauses were written in a way that could have allowed DAOsquare to withhold payment at their discretion.

**Next Step**: We should have some 'good' written terms for the sole purpose of clarity of expectation on both sides, granted clauses they are written with precise triggers. Some examples below:
- Clarity around what constitutes a "bug", and whether certain ones are development mistakes or part of a normal development process.
- If / how much we will charge to fix an audit that flags issues
- Timing of payment after work is complete
- etc.

For terms that pose a risk or are written vaguely to the benefit of the client, we should price in that risk accordingly and explain why we need to charge for the client's additional insurance.