David,
Thanks for your input. My client's needs were really pretty simple: a back
end to enter items to sell and report on what's been sold, a shopping cart,
and integration with Stripe.js, which they were keen on ("credit card
numbers never hit your server!"). They wanted this as part of a perhaps six
to ten page site with some CMS capability to change a few things. Spree
just seemed to be overkill, not flexible, and not a good fit. ror-ecommerce
seemed rather risky, with one person maintaining it. Only option left
seemed to be to write it from scratch.
Then I stumbled upon Piggybak. Created by a group with lots of e-commerce
and Spree experience as a gem. Tying into RailsAdmin for the back end, it
looked perfect for my limited needs. It is an add-on to an existing site,
not a complete site. It had features like supporting varieties of the same
product, such as different quantities, and they were willing (for some $ of
course) to add a Stripe module. It looked mature enough to depend on. I got
a signature on a contract and a deposit and built the site and some of the
e-commerce part.
Then, disaster. Immediately, the creators of Piggybak embarked on a major
refactoring, and based the new Stripe module on this. The new version was
released with many, many bugs. I spent some client money debugging it, and
a bunch of uncompensated time as well. Would-be freelancers, take note.
Your contract should make mention of factors beyond your control, as mine
does, and make clear that all such risks are assumed by the client. I just
wanted to salvage the project even if it cost me.
Could I have asked them to base the Stripe module on the old version of
Piggybak? Only if they had given me that option. And I wouldn't have taken
it. Who wants to be tied to an older version of a gem?
We finally killed most of the bugs, but what killed the project was of
course the budget. The client wanted guarantees I could finish within $X
because they had an overall budget in mind that they didn't communicate to
me earlier. I figured it would take $2X at least, and possible more, since
I work strictly on a time and materials basis.
Piggybak is a good idea and I hope they succeed with it, but it failed for
this project.
Scott
On Wednesday, February 27, 2013 12:36:56 PM UTC-8, David Henner wrote:
>
> Scott,
>
> That article is very old so take it with a grain of salt now. I wrote it
> so... All being said, Spree appears to have addressed many of the issues.
> I still have issues with their solution but I also think it works
> depending on what you want to do.
>
> I would not expect to customize spree and expect to upgrade spree though.
> I've been on a couple spree projects and most eventually start tearing out
> spree's core if they become really big. Everything being said Spree is
> MUCH better than starting a project from scratch. The number of mistakes
> that can be made are numerous.
>
> At the end of the day you should give spree and ror_ecommerce a test drive
> before committing to either solution.
>
> I assume your project is already being built. I'd love to hear how things
> are progressing.
>
> Dave
>
> On Sunday, August 12, 2012 10:03:21 PM UTC-7, Scott Olmsted wrote:
>>
>> Anyone used Spree or ror_ecommerce for an e-commerce site? My client
>> wants to sell biological samples by credit card or purchase order, post a
>> few pdfs and other files on the page for each product, and perhaps export a
>> file to Quickbooks, including taxable status. Will customizing Spree take
>> longer than creating from scratch? What about using ror_ecommerce? Any
>> validity to the author's claims and criticisms of Spree? (
>> http://ror-e.com/posts/1)
>>
>> Thanks, Scott
>>
>
--
--
SD Ruby mailing list
[email protected]
http://groups.google.com/group/sdruby
---
You received this message because you are subscribed to the Google Groups "SD
Ruby" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
