CSA subscription contracts management feature: oportunity in France with the CSA network

There are 2000 CSA in France (AMAP). The way they work is based on subscription, in the literal meaning of the term, so members of a CSA buy a subscription to a certain basket for 6 months or a year, and then receive the content from the subscription contract on the agreed upon pace.

The CSA network in France is represented by one association who have developed since 3 years a software where CSA can establish subscriptions contracts, manage digital signature, and amendements in the contract life cycle. After 3 years of development, their developer is stopping to work on the project, so they are looking for another contractor to develop their software and published a request for proposal with some requests for adjustments and new devs as well on their software.

We had a couple of conversations with them and @Rachel , and there is a possibility for Open Food France to propose them to join and instead of developing their own software on their side, develop a module within the OFN, so they don’t have to maintain it alone, investment cost can be shared with other interested network worldwide, maintenance cost is not on them, what they do has a greater impact, their producers can also share their catalog with other distributors, etc. They are open to that idea, but they have some imperatives, and among them: they want around Spring 2019 to have a functional software that does what their software do today and some first complementary things that are in their Request For Proposal.

We will start to work with Rachel on some first brain ditch on how would a “contract based subscription” module / CSA subscription module look like in the OFN. The logic is actually a bit different from the current standing orders ones, as in a subscription, what is sold is not products, but a subscription. So the invoice is hold when a subscriber buys a subscription and then deliveries are only the delivery of the content planned in the subscription contract, but products are not invoiced Transaction is not on products. Some of the current standing orders logic will probably be used, but with adjustments.

But before we move forward with the idea to propose them to join and build it with us, we want to jauge how much of a priority that could be within the OFN community. As if they follow us on that proposal they need to have something functional by Spring. We have prioritized Split Payments to go next as a big feature, and still have work on Spree until at least end of year. So how would the priority in CSA subscription feature be for you? If we gain such a big partner in France and who can also contribute $? (we don’t know budget yet).

Some first thoughts and mockup on how this could work given our OFN contraints… so that we can decide if that worth moving forward on thinking in that direction, or directly go toward an integration strategy: https://docs.google.com/presentation/d/1btGtJs25WsLPdEuKariWQUvnzOHfTE0kCCqv9vkenRM/edit?usp=sharing

Proposition: to understand how CSA works in the different countries via filling in this spreadsheet: https://docs.google.com/spreadsheets/d/17vTEg78GBuNkBIyPt-imoI_YB20nUWxWzTUAAdvUjew/edit#gid=0 before seeing how we can implement it in OFN.

@Kirsten @sstead @NickWeir @lin_d_hop @tschumilas @sauloperez @saritamoreira @lauriewayne @lauriewayne1

Given your feedback, we will decide if we answer or not this RFP based on on OFN, or on their sofwtare, or if we don’t.

1 Like

I’d be excited to prioritize a CSA module, and I like that they have a firm deadline for a functional module - it will be good for us to work to a deadline! CSAs in Can are not as organized or centrally coordinated as in France. No one knows how many there are. But I know that there are at least 200 in my province (Ontario) alone - because I inventoried them a few years ago. A group here in Ontario (EFAO - Ecological Farmers Association of Ontario) wants to develop a program to support and help market CSAs in the province. They have been in discussion with me re: how can OFN meet this need at present, and in the future (since I told them that full CSA capacity would be down the road.). Of course, they have no money. But there is always the possibility that OFN-CAN can work with them to write a funding proposal. No guarantees - but I’d say there is a good chance OFN-CAN can contribute something. I also think its good to have existing groups who know what they need/want to work with. I haven’t gotten as far as documenting their exact use cases yet - but I could do so - would that be helpful to you? For example, I know that here, the CSA business model is actually several different business models, and not just one thing. For examples…

  1. single farm CSA - ‘subscription’ - as you describe above, but with the option to buy additional products the farm as available each week as ‘extras’ (so a farm store + CSA)
  2. multi-farm CSA - aggregation model where a farm is like a food hub - but sells subscriptions. This model needs the OFN aggregation logistics to help them source and supply each week’s box. Generally there is a sharing approach, not a simple mark-up like in a food hub - so could have more complicated fee structures. Really they need advance planning tools too - to plan for who grows what - but maybe that’s not in scope here
  3. food box type CSA - this is like a multi-farm CSA, but the coordinator is not a farm. Generally these are coordinated by urban companies, and generally big on delivery/drop spots - so they are very much like what OFN calls ‘food hubs’ . They add a mark-up… just like other food hubs.

For all of these, we’d need capacity to:

  • set, and promote drop spots - different mix of products maybe at different spots (like distributors now)
  • have people choose drop spots, and change what drop spot they are going to - as we’ve said before - people keep creating enterprises as distributors where they don’t want to in OFN because thats the only way to map a location
  • back end aggregation logistics re: what products are going into the ‘shares’ each week, and where are they coming from…
  • customer/shareholder signup, and managment of their contracts (ie - changing the pickup location, going on vacation and someone else will pick up…) - OFN doesn’t have anything like this now
  • WAY BETTER establishment and management of customer preferences and lists - CSAs here are member management intensive - all the other platforms in use give much more priority to these functions than OFN - so without this, I would say we shouldn’t bother trying to do CSA software.

Exciting potential!!

In the UK there is a CSA network which is a loose coordination of many different types of CSA.
Many of these CSAs are interested in OFN and I think would be very interested to cooperate with a French project along these lines. There is not much money about within the network but I would be happy to explore fundraising in cooperation with several interested CSAs.

In terms of prioritisation… the pipeline looks very full already. It would be a difficult decision to postpone split payments… Maybe we need to have a zoom call to discuss this.

Thank you @tschumilas @NickWeir for your quick feedbacks. I will share soon some first thoughts to clarify what I start to forsee, and we can see from one “main case” what other cases of CSA diverge from this one.
But when working on this I realize how specific the CSA organization is compared to our model… and I’m wondering if drawing the OFN line before the CSA and integrating with another dedicated software might not be a better strategy.
For instance in France there is http://amapj.fr/download.html used by 160 CSA, AGPL, pretty well maintained. If we APIs ourselves that might be some interesting case to work on. Maybe a better strategy than building the whole CSA logic, which on certain aspects I’m not even sure are compatible with some fundamentals of OFN… i’m working on a presentation to explain what it would mean to handle it within OFN so that we can build some vision about building in vs integration strategy…

My thoughts are that we could then support and contribute to some other software we want to intergate with so that they meet our need… instead of trying to do everything in OFN… which might make the software so complex and unmaintainable…

@MyriamBoure what do we know about their existing software? what is it built in and what state is it in? Given their timelines and the fullness of our pipe I wonder if a possible approach would be to expand our global team with the skills to takeover management of their existing software, triaging it to keep them going but not heavily investing in further development. Then we would have more time to really get across what they’re doing and work out how best to merge / move efforts across to OFN without them losing existing service when their devs go away?

1 Like

@Kirsten their software Clic’AMAP (access codes here to play with it) is in PHP. Yes what you suggest could be a solution, to recruit some freelance within our community to work on their software. But in their criteria they don’t want to depend on only one devs, they had issues with their dev being out of office for 2 months and don’t want to reproduce that again, so it means if we “onboard” a PHP dev we need at least to be able to find some “replacement dev” in case she can’t work for a while… Also today everything is in French in the software. And they want some improvements they don’t want to negotiate on, like dematerialized payments and have run some democratic process within their network to choose which solution they want to implement. So if we go there they would prioritize what to work on and we would do it… what I’m a bit annoyed by is that today their software is not really open source. They might want to open it up though. But their competitor Amapji(in Java) is open source, and I’m wondering why they didn’t cooperate in building one software… But I like your “intermediate proposal”, invite them in our community and recruit the devs to work on their project, learn also through that process, and then see how to slowly move them to OFN (or build connector if we decide it’s best strategy)… @Rachel what do you think about that?

@Kirsten @NickWeir @tschumilas
Some first thoughts and mockup on how this could work given our OFN contraints… so that we can decide if that worth moving forward on thinking in that direction, or directly go toward an integration strategy: https://docs.google.com/presentation/d/1btGtJs25WsLPdEuKariWQUvnzOHfTE0kCCqv9vkenRM/edit?usp=sharing
100% draft mode, look especially from slide 9 to 15, before are thoughts to understand the CSA model and impact on OFN.

started to go through this @MyriamBoure but my brain started to hurt. I’ll take another look when I’m fresher - its getting way more complicated than i thought. I think there must be an easier way to harmonize this with OFN as it currently exists. For example - lets think about 2 CSA general types: 1. single producer sells own product as shares, 2. multi-farm CSA - which is a hub basically - that aggragates from multiple producers (sometimes people call these ‘box programs’ here). So for the single producer - their ‘share’ is just another product - lets call it ‘food box’. But the current problem is, the producer wants to sell other products weekly - eventhough the customer has already bought a ‘food box’. So - is there a way in our current shop front where, once a product has been purchsed by a customer (so once I’ve purchased a ‘food box’) it doesn’t show up again until my subscription is over. Then, as a customer/member, I go to the existing shopfront, buy anything extra, and choose delivery options for my order. I receive my weekly ‘food box’ as previously paid for, plus new items for the week … would something like that work? For case #2 - multi-farm CSAs/food boxes - aggregation is needed, and of course thats what OFN is designed to do. So I like the idea of basically making this a kind of hub, but where the csa manager ‘selects’ the products from the various producers, not the consumer. I’ll comment more on your file soon - but a group of us might need a zoom call on this one.

Great work Myriam.

I have one concern/question:

  • “when a delivery happens it’s not an order, it’s a “CSA delivery” and it’s possible to issue delivery note but not invoice on it.”

Why do you think we cant adapt to the existing model of having a subscription creating the orders automatically? This is already done in current subscriptions I believe. The contract is the subscription and the “deliveries” are orders. We could then say these orders are already payed at contract level and do not have payment or invoice (like the orders in the current subscriptions do) but they would have everything else, and they would be just orders in the system.

We have two types of CSAs each year that go through our system (OFS). One is a single farm CSA, and the ‘sale’ is simply buying a share for the season at a price the farm determines. They look after managing their customer list and what they will put in the customer’s box each week. It’s based purely on what they have in season that week, and first picks of produce will generally go to CSA holders before it gets listed for general sale. Customers are free to order whatever else they want week to week. The CSA is paid for in advance, all at once, for the growing season. (Usually late June through early October here.)

The other is a “locavore” box that we assemble seasonally. Our producers make some products available to us at wholesale prices to include, and our hub coordinator is in charge of ordering enough from any and all of our producers to create a box of a certain value. These are normally done once per month, and, as with the single-farm CSA, is purchased and paid for in advance each season. They normally run quarterly.

So the ‘two type’ model @tschumilas mentioned would be a fine fit for us as well.

@tschumilas I understand your point and thought about this first, but I have a question: what technically is a “share”? Because I investigated and realized that when you buy a “share” you don’t buy a product, you buy a subscription for a product that is going to be delivered weekly. In OFN until now we only sell product. If you buy a subscription, you need an invoice for the thing you bought. So we need to be able to issue an invoice for the sale of a subscription. But then every week, it is not an order that is made, it is the realization of the previous order, the subscription order. So we can’t treat the veggi box that is part of the subscription like a product in a cart that you just can’t remove, because if we do it will be on the order for the week. How do we manage the invoicing then?
Can you confim that in Canada a “Share” is also technically speaking a subscription? See https://www.mazars.fr/content/download/734218/38544311/version//file/IFRS%2015_04092015.pdf for the details on the legal treatment of this type of sale. Do CSA also make customers sign a “contract”? It can be in some sales conditions, etc. But I want to understand the legal treatment of it so that we propose something aligned…

Else maybe another way to treat them could be to “tag” somehow a product as “non invoicable” so that even if it is in a cart it is not invoiced on the weekly order… but we still need to build something to handle this new type of product for sale which is a subscription, with a contractual agreement attached.

So @luisramos0

We could then say these orders are already payed at contract level and do not have payment or invoice

Yes actually that could work but:
1- the subscription items should be impossible to remove from the order (contractual agreement) so if a basket has been postponed by the customer it will just not appear this week in the order.
2- One point which is more complex, is that if you want to handle multi-farm CSA, with some “hub” organizing sales for multiple farmers, then we need to implement et new type of OC where the hub is just a sales facilitator and orders directly go to every producer and invoices are issued by the producers.
3- And still the CSA subscription should be linked to a contract so the product and associated price should be “locked” in the system to products in CSA contracts should not be editable once a contract has been signed.
4- AND it would be another type of subscription with a contract attached which is not the logic of standing orders…

Do you think all that is doable? :wink:

Thanks @MyriamBoure this is amazing. I have been through the slides and can’t think of anything to add. It is a LONG time since I administered a CSA but I have contacts I could ask to go through this and make comments if that would be helpful.

I agree that this is going to be complicated for the users and think we will need to offer a set up service for CSAs so that they tell us how their CSA works and we do the initial set up for them before handing it over to them - maybe with some training. Or maybe the setup and training could be funded through CSA network groups.

Most CSAs in Canada sell under 100 shares - and are pretty informal. They don’t really follow and legal requirements like contracts. Most have a verbal agreement, some issue an informal areement that the member signs (ie: I agree to pick up my share, I understand that particular veg may not be available, If I don’t pick up my share I can’t just pick it up later…) Some farms have work exchange requirements and then that would be in this letter also. So here, farmers would be hapy to write their own letter (‘agreement’) and send that to members who sign up - we wouldn’t need this to be part of OFN.

The term ‘share’ comes from the original CSA models in Can and the US. It means a person is buying (in advance ) a portion or ‘share’ of the farmers harvest, and thus giving them money in advance so the farmer can buy seeds and inputs. It also means the buyer is taking some of the risk of production with the farmer. It also means the products are ‘farmer choice’ not ‘consumer choice’ (and this is why we call CSAs ‘other-than-capitalist economics’.

But in OFN, I think of a ‘share’ as a composite product. Isn’t it? Isn’t it like applesauce or salsa? A share is a product that is composed of other products. And we want to eventually move to this capacity in OFN don’t we?

Maybe in OFN the product is one food box/basket. And a share is x number of weeks of baskets/boxes. So then repeating order should work. (I think for you the contractual agreement means its a subscription not a repeating order maybe?) BUT we need the capacity for advance payment. That is what we don’t have. So someone would set up a repeating order for x number of boxes/baskets, pay for those products in advance, but still see other products in the OC and add them into their order. Their first invoice - the week they make the ‘share’ purchase - would invoice them for x number of boxes/weeks in advance-- and it could identify the future delivery dates. Plus it would identify anything in addition they bought in that OC. After that, we don’t want that ‘member’ to see the share as a product (because it can only be bought once).
We could remove it for members with tagging I guess. ?

Does the contract have to be automated? If a buyer gets an OFN invoice that shows they bought x weeks of boxes/baskets, and the price, and the delivery dates - is that enough? Could the customers who buy that be sent a contract to sign outside of OFN? Maybe we automate that via mailchimp or something?

With regard to multi farm CSA - isn’t the enterprise/farmer who sells/administers the shares like Mary? She buys from Freds, modifies the product (assembles the boxes/baskets) and sells the composite product to Jane. Right now we have hubs doing this. Mary plans (outside of OFN) what is in the basket/box and lists it in the OC. Mary orders the ‘ingredients’ she needs from Freds each week. Jane orders too and the orders get totaled and communicated to Freds. When the products arrive, Mary assembles the baskets/boxes that were ordered. OFN invoices Jane (invoice includes the box) Fred invoices Jane (invoice include the ‘ingredients’ Jane used in the basket. So all this works - its just that we need payment in advance for x boxes/baskets and we need the invoice to show that, and to show they are already paid for.

I can’t help but feeling we are already really close to this.

1 Like

I have this conversation marked for a closer examination when i have some headspace but must admit I am very relieved to scan @tschumilas’s last post. I think there is a massive risk of over-complicating and creating a whole lot of unnecessary extra stuff. Two things to consider:

  • what of the way they currently work can we already cover with existing functionality
  • [big part of discussions in dec] is there actually value in writing a whole lot of code to accomodate exactly what they do now? or is there a way that their model can also evolve e.g. CSAs were created before auto-billing of credit cards was an option. The decision to prioritise that for subscriptions was based on the ease and acceptability of that method of payment across a whole lot of things that people are now used to. If that is not acceptable, then I tend to think that account credit and upfront payment, alongside existing subscriptions (phase 2/3) would probably do the trick.
  • when a customer ticks a box to authorise the hub to hit their credit card there is a contract. At the moment it is not clear, but perhaps somekind of notification at that point would be sufficient
  • i can’t see what a ‘share’ can’t be a product and treated as such, therefore making existing subscriptions just fine
1 Like

I’ll just say that in Aus I haven’t heard from anyone specifically requesting CSA contracting functionality. We have had requests for a payment wallet/prepaying for seasons. Also had a request for annual membership fee management, but not specifically contracts.

I think that’s a main and BIG difference that we will need to work on… CSAs in France have been annoyed buy the legal and sanitary administration for years, who wanted to shut them down or requalify them to avoid some “unfair competition with real businesses”… so they came up with this contractual form to protect themselves.

Can the “letter” or “informal agreement” be something that would make it worth sign online when the customer buy a “share”? It would be some local template of a “contract”. Actually any producer should be able to issue the contract they want, but we need some form of local guidance to help them put in it what will protect them. Like “terms of sales”. Each farmer who sales has implicitly today some “terms of sales” where she could write that "for this type of product, here is how it works, etc. If you purchase it you confirm that you agree with the term of the present contract, etc."
What the CSA in France have done is make explicit those contracts to protect this distribution model that was under threat.

Re. “share”, I think your definition is very much the same as what it is in France, but we just talk about “basket contrat or basket subscription” in France. Most farmers have one or two CSA they sell through, so they have some stable income for “baskets” they compose themselves. And the rest of the production is sold through markets, wholesalers, farmshops, etc.

I agree that a “share” could be seen not as a “subscription” but as a “pack of products” that you buy in advance. But I ask you to check with legal experts @tschumilas in Can, and I’m doing the same in France, what is the “legal” nature of the share. We can’t tell how to set it up in OFN before we understand that. How does the producer write the sale in their accounting? Do they sell one product which is a “pack of baskets” and register in their accounting an advance payment, and recognize then the turnover associated at each delivery for the corresponding amount? OR do they register it like a subscription to a product that is fully paid so it’s not an advance payment, but again the turnover is recognized when the baskets are delivered each week? It can’t be both, we need to know what it is. Our chance is that accounting norms are international since IFRS so should be the same hopefully :wink:

With the new product chain model we plan to implement, we could imagine to sell a “composite product” yes that will then be a sum of 1 basket of week 1 + 1 basket of week 2, etc. So then if the composite product is bought, we need to be able to manage “partial deliveries” within the delivery note model, and make sure what is invoiced can be different from what is delivered because some things in the delivery note will be deliveries of things invoiced previously :-o It complicates a bit more the logic but I guess it’s doable, we just need not to base the invoice on the delivery note but on the actual sales. (ping @Rachel)

If the share is a composite product I don’t see today how repeating order would fit the need we have here… because in our product chain model, the basket for every week will be a different product, basket of week 1 will be different from basket of week 2. So in the case of a composite product it’s not a repeating order of the same product, it’s just a “product recipe” matching one pack with 40 different baskets. Repeating order means you order the SAME product every week. Here baskets vary every week.

So you say two things contradictory to me : either it is a composite product, either it is “buying x number of week of basket” which is a subscription.

How do you “sell” x number of weeks of baskets IN OFN? Today setting up a subscription is manually done by a hub manager. What is the mechanism for a user to “buy x number of weeks of baskets”? online? Without having to call and do it informally? For me this is what is a subscription contract that we are missing today. Having a contract outside OFN means selling outside OFN as a subscription contract is the producer “terms of sales” somehow.

@Kirsten it’s not about accommodating what they do for me but understanding how CSA work on a legal aspect if we want to propose a way to manage CSA…
I agree that advance payment might be needed if we agree a share is a composite product, and maybe we can reuse some of the current standing order code if we agree a share is a subscription But still we need to know what are the operational CSA rules. For instance in the way CSA operate today you can plan “holiday weeks” where your basket won’t be delivered. So it means having “custom schedules” or more flexible subscription periods with weeks of pause where you don’t receive your basket. But when you don’t receive a basket you can “postpone it” on some other week. How do we do that with the current standing order feature?

So from where we are at, I think we need every instance to do a real investigation job to understand the legal aspect of “shares” sales (composite product paid in advance or subscription), and associated rules (pause basket, postpone basket on another week, etc.) even before starting to think about implementation. On a short term I will just tell the French CSA network that investigating on how we could build a CSA feature in OFN that would work for any CSA case in the world will take time but we want to invite them in this process.

So @Rachel will answer on her side with HappyDev or some PHP dev team she founds to maintain and improve their current functional software.
On my side I will propose them a partnership, to join the cooperative we are building in France and investigate with us in this broader conversation, even if they keep on using their platform. So there will be no money associated, but their knowledge can be precious. I will try to invite Urgencii as well which is the international CSA network. They probably know the legality of CSA pretty well…

Sorry for the long post… I didn’t have the time to try to make it shorter :wink:

I started listing things we need to clarify about understanding the CSA models in each country: https://docs.google.com/spreadsheets/d/17vTEg78GBuNkBIyPt-imoI_YB20nUWxWzTUAAdvUjew/edit#gid=0 maybe we can use it to compare how CSA works here or there? Feel free to add columns if I forgot some dimensions…

(Side point but very connected to this discussion: I’ve been asked by french users how they communicate about their term of sales and make their customer accept it when they buy. This is a legal requirement for commercial enterprises, when you sell you always have a contract that your customer needs to accept. I will open a wishlist on that when I have time. On some platforms like Amazon sellers are under terms of sale of platform. We have neither in OFN.)

I had an awesome meeting today with the CSA network in France. We have in the OFN network and the CSA network in France very similar organizational architectures, and a 100 % cultural fit. We share the vision, and what we stand for. I exposed clearly the OFN, the three layers of commons, the difference between software and Saas and economic model we can build on open source software, our priorization processes, onboarding processes, etc.

The super positive outcome of this conversation :

  • There is a real interest on their side to join the cooperative we are building in France as cofounders and contribute, with knowledge and money, to integrate within the OFN the features CSA need. So the plan we started to discuss was a tripartite convention with them, Open Food France, and HappyDev or equivalent (through Rachel). HappyDev would ensure the sys admin and minimum maintenance of their current software, to ensure continuation of service for their users. Until the OFN that they would contribute to is ready to welcome them. That’s what we are going to propose.

  • They understand our priorization and concertation process and are happy to take part in it. They understand their need are among other needs. They would be reassured to have some deadline, like for example if we could say that we decently think that within 3 years they will be able to meet the major needs of their CSA hubs, that would make their decision easier. I told that it’s hard for us to commit on those things given the processes we establish…

  • They understand the interest of building things for the global community of CSA and are SUPER happy to participate to analyze the various operating mode of CSA in the world, which is the first step of understanding before we even talk about the need. So documenting and sharing that knowledge is also super interesting for them.

  • They are open to review also the « contractual process » they have implemented today. They confirmed that the CSA contract is basically a « term of sales », that is compulsory for any type of sale, but this one is written to make the customer conscious of the commitment she takes and especially, the share of risk with the farmer. But they agree that there could be other ways to do that that worth exploring, like for example, when you buy a CSA share, the purchasing process could include a modal showing the most important commitment of the customer, and in a gamified way, ask some quiz to the customer to make sure they read what they commit to, before they can complete the purchase.

  • They understand that they might not be able to do everything as they do today in their software, but the idea is to find a way to meet their need.

The pain point :

  • I asked them about the legal consideration of a « share » in France. We are going to check with legal and accounting expert, but it seems shares are treated as subscriptions, like when you subscribe to a magazine. So you buy the subscription, receive the invoice, and the amount is due at the moment you buy the subscription. A term of sales is attached to that sales, specific for the subscription type of sales (their CSA contract today). CSA can offer payment facilities, like in 10 times, to make this subscription more accessible to low income people for instance.

  • That means there is really a specific rethinking to operate within the OFN about « how do we sell subscriptions » and not « pre-sale of packs of 30 baskets »… which is a bit what I started doing in my first brain dump mockups.

  • I’m suspecting this legal treatment would be the same in other places in the world… but would need other instances to investigate with legale and accounting experts from the CSA local networks.

@tschumilas @Rachel @Kirsten @luisramos0 I’ll come up with a plan tomorrow for our call. I really think the CSA community is a big and strategic worldwide community that has an important role to play in the future of the OFN…


Looking forward to more discussion on this. And maybe you can explain on our call why ‘pre-sale of 30 baskets’ is not a ‘subscription’? Its like - pre-sale of 12 magazine issues. Isn’t it? OFN can do this now - right? Except we need: 1. an option to link to some type of contractual agreement (that could be optional for the user) and 2. A way to not offer the subscription (30 baskets) for sale again once its been purchased. (tagging would do this now I think - but its a pain.) and 3. a way to defer payments. All of these features would be useful beyond CSAs also. I think the bigger need is the capacity for the purchaser to interact with their subscription and modify it. Thats a feature we don’ t have at all yet. I wonder if there is a way to hack together a quick start for CSA now, and then take 3 years, in partnerhip with this group and maybe others, to develop a community generated solution. Talk tomorrow.