Do you need to be an expert in coding to build a successful startup??

Hi Cornell

Thanks for sharing your blow by blow experience with Developers.

Golden tips throughout your post. I have a question about the "Blueprints"

You mentioned YOU prepared 2. The second Blueprint was 40+ pages of instruction. How did you "learn" to prepare these blueprints?? Trial and Error or did you follow a template of some kind. Any resources which you found helpful?

Hmm I would suspect that a "non-coder" would do well to learn how to write up the Blueprint. This would provide CLARITY both to oneself AND to the developer and save time.

Thanks Cornell for sharing your Experience.

P.S
How many were on your team for your projects? From your post it sounded like you had a partner. Were they a coder? What skillset did they bring to the table?

Just trying to get a clearer picture of the team as I found this most valuable in my own experience.

Thanks again

Originally Posted by Cornell

No...but you have to know what you want and how you expect it to function and be able to communicate this in clear and concise terms....and hope you have made the right choice in a developer.

Ankesh is correct in saying you have to find the good developer.

I am not a coder and the first foray into having software developed resulted in several months of a bad coder wasting time and ended up in us having a successful lawsuit against him. He came with glorious testimonials and was well known on the forums but the fact was that he was nothing but a shyster.

Just a hint (in case you pick an incompetent developer)....when you enter into the contract with a developer make sure that there is a clause that any and all emails, PM's, ICQ messages or other forms of communication are parcel and part of the contract....and keep and store all communications.

Our second developer was great but ran into a personal dilemma and abandoned us (understandably given the circumstances) but he laid the ground work, the basic backbone of the software (incidentally he is back working with us when needed)

Our third and final developers we found in S. America and we have been with them for just about 10 years now.

You need to write a complex blueprint of exactly how you expect it to work (leaving out nothing), how all the functions will interact., etc., before turning it over to a developer. While even a great developer can't read your mind they will advise you what can and can't be done according to the guidelines set out in the blueprint....and a good developer will find or suggest a workaround or alternative for things you have specified but can't be done exactly as you have said in the blueprint.

I did 2 blueprints.....

one an overview for the different developers to look at and use as a basis for giving a bid on the work.

second was comprehensive for the selected developer....took a full week and some 40+ pages laying it all out in black and white.

If you are lucky enough to find a good developer and keep them....after a period of time you will develop a synergy with them...the developer knowing what you expect and you knowing what the developer is capable of doing....more than anything a trust in each other.

Good developers aren't cheap.... they really are worth their weight in gold when you find them.... pay them well and above all treat them well.

Most bargain basement developers will end up giving you mile high headaches.

WOW! Thanks for the "Tidbits". You can ignore my "P.S" in my previous post. you answered my question here about your team.

And you hit on a CRITICAL point about SUPPORT. I am jumping up and down agreeing with you. This is like a Blindspot, that some small business owners just don't THINK THROUGH.

This was one of the major reasons I've "shied" away from looking at software type solutions. The cost of maintenance/support is sometimes NOT worth the effort.

We used to run a Help Desk for some clients and while I was greatful to provide the service and add value, I still have some "shell shock" from the quantity of SIMPLE to ABSURD requests that come through. ( A Lot of the questions were NOT related to I.T AT ALL. Hence my "Absurd" comment )

The volume can quickly become overwhelming if you are not prepared.

Thanks again Cornell

Originally Posted by Cornell

Hi Dien:

Thanks for mentioning the software.

My partner and I did develop the AthenaGold software.

When we started out we had a $15,000 budget....well....we have blown that right into outer space with costs that hit 6 figures 2 years ago....that is just developers fees by the way.

If you don't mind I would just like to input a bit more.

People that decide to have a script written generally overlook an area that can be a killer.... and that is support. It gets very costly and time consuming and someone has to be paid to do it.

A little $37 or $47 script that gets developed and sold is cool, and if it catches the sales could go into the 1000's. of copies...if a script sold 5,000 copies at a $47 one time fee it would yield $235,000 in sales....

Now just imagine 5,000 users hitting you for support...and no matter how simple the script is the requests will come. And they will continue as long as the software is being used (Heck...Bill Myers discontinued support on his eShowcase V2 software back in the late 90's after he sold it and the the new owners pretty much stopped supporting V2......I still field 4 or 5 requests for assistance with it every year even though it is so outdated and insecure that it shouldn't be used).

It won't take long for the support and further bugs, etc., to eat into that nice big figure that was so enticing.

So....if you are considering software script development you need to be aware of this and I would suggest selling the script on a continuity basis (membership)....even if it is just a few dollars a month. If you don't have a residual income coming in the ongoing costs of support are going to eat you up.

Another area of concern is security....

The last thing you want is a major law suit because your script was vulnerable and a hacker figured out how to use it to break into a site or server.

We spent a full six months on security development alone. We have so many failsafes built in that it would make your head spin....We get detailed reports from the software each and every day of failed attempts to break in....not just on our own sites but on sites that have the software installed on them...we get everything in the report - the site attempted, the url attempted, any code they tried to enter, time, IP address, the hosting server from which the attempt came, and lots more. We even get a detailed report on each and every install where suspicious activity (such as incorrect login info) has occurred on the login to the admin area.

Those are just a couple of more tidbits to consider if and when you get the script development bug )

Again ...thanks Dien.

Cornell

[Ankesh]

Thanks Duane

I can't create the tech I want. That makes me a non-technical founder. Over the years however, I've learnt how to talk with technical folks to get the problems solved. I can bs my way in technical talk

(I've tried learning programming on my own a couple of times before but haven't followed through. Maybe this time, it'll be different with udacity.com and codeyear.com...)

My team... we have an office. But we also have a couple of folks working remotely. (We are a team of 6 people right now.) Given a choice, I would always prefer a single office space. Keeps folks more accountable. But I go where the awesome talent is. And so, we do hire remotely too.

To keep things moving well with remote workers, you need to: have a lot better documentation. Wireframes and screen shots and explanations. With people in the office itself, napkin plans also work. Because the feedback is more constant. But remote workers need more details to avoid communication gaps.

Feedback and communication. This is what is important. I get my remote employees to talk with everyone on the team. And not just talk with me or a project manager. This makes them feel involved. Makes them learn and share with other folks. Will be planning a week long get together for the entire team too - but haven't done that yet.

1. Weekly team conferences. For people who are remote, can join in via skype.

2. Get everyone to talk with everyone. No project manager handles communication stuff.

3. Face time is pretty important. So once a year, getting everyone under one roof would help a lot.

4. Sharing of ideas and knowledge and new stuff. Having a bi-weekly employee email is awesome.

5. Accountability. 6 monthly reviews. Weekly task lists. Daily i-did-this updates.

Hi Duane:

How did I learn )

I didn't really.

I just approached it as describing how I saw the software working and interacting with the user and within itself....I sat in 3 different situations...1 as the visitor, 1 as the web site owner, and 1 as the developer. I knew what I wanted the software to do so in my mind I went through each step a visitor to the site would go through in using the site. As the site owner I looked at what I would have to do to set each and every step up to make it all work. And as the developer - can I understand what his guy is trying to tell me.

To answer your questions this is going to be a long post and I may have to spread it over 2 posts.

To give an example I'll have to use our software...it is web site building, content management, etc.

Just like writing a book I started with an overview of what I wanted the software to be able to do and its purpose.

Then I sectioned it off into sections such as templates, graphics, affiliates, products, forums, blogs, eCommerce, etc.

Then I sub headed each section...for example templates...design, functionality, editing, graphics, WYSISYG editor, etc.

Then I simply described my vision of each and the interaction that I felt was needed and also added more sub-sub headings as needed under each sub heading.

Then for each subheading I did a summary, and again at the end of each section a summary.

This sounds rather simple but actually it is quite complex as if you don't lay it out exactly the developer can only second guess what you really want and also cost a lot of money if they have to redo things.

Just a quick example...let's take something relatively simple that everyone has some experience with...shopping cart...


Section: eCommerce

Sub Headings: Display, Checkout, Continue Shopping,Taxes, Shipping, Carriers, Payment Gateways, Special Codes, emails,...and several more and none in a specific order here.

So under the Sub Heading 'Payment Gateways' it would be something like this:

Software must be able to interact with api gateways to process credit card purchases (ie: Authorizenet), third party gateways (ie: PayPal), self testing software gateway.

Software must provide option of choice for the 4 default api gateways with integration into these api's and configuration area as required by each by the user. After configuring by the user the software must apply the configuration in the install and provide encrypted setting of same. Api's to be obtained by developer from gateway's sites.

Software must provide third party section to accomodate system such as PayPal with a configuring area to enter users PayPal information and then apply configuration in the install and provide encrypted setting of same. Developers must program to interact with PayPal as per info obtained from PayPal. This configuration must also include optional use of PayPal sandbox with user able to select that mode and also turn off that mode. Software must recognize when sandbox setting is enabled.

Self testing must be written by the developer to allow the use of false credit card info to do a false system check by the user such that the shopping cart is completely functional such that when an order is purchased while self testing is enabled, the the cart processes the payment throughout the system including the sending of emails to the user, the site owner, and other systems within the software that are tied into the type of purchase according to settings for the different classes/types of products, shipping settings, carrier settings, etc. This system will over ride all other settings for the payment gateways while it is marked to be in use. When canceled then the selected and configured gateways will then be applied to the shopping cart.

Summary:

This section should be accessible by a link from the eCommerce main page.

All options must be on the same page with headings clearly marked. Within each section for each heading there must be a configuration button to open a window where user can input necessary info and then an apply button to apply his configuration to the software. Window will close when apply button is clicked and the information has been added to the software and successfully encrypted.

A secondary radio button is to be available in each section to be marked by the user to indicate which of the configurations are to be applied to the cart and when selected the software will implement these as options at the time of selection of the checkout button on the shopping cart with display as noted in the Sub Heading section under eCommerce named 'Display'.

It is to be noted that only one default api gateway can be selected at any given time and if more than one is selected software must provide a warning screen that selection is incorrect and that only one can be checked for use.

I should also be noted that third party gateways can be used in addition to the default api gateway.

It should be noted that when the self test is activated that at the completion of a test of the shopping cart a popup warning be displayed on the screen to remind the user to return and disable the self test when finished. Secondarily the software will send an email to the site owner if the shopping cart sits idle for a period of 15 minutes while the software is in self testing mode with a warning that the self testing mode is still activated. This process will continue in 15 minute intervals until the self testing has be turned off.

It should be noted that when sandbox is selected in the PAyPal configuration and is not deactivated after a period of 30 minutes an email is to be sent to the owner notifying owner that sandbox has not been deactivated. This process will continue in 30 minute intervals until the sandbox has been deactivated.

Just a bit of an example...shortened just to give an idea of what was needed....some of the descriptions above would have been even more expanded as needed.

We had many conferences with the developers on the blueprint to clarify and answer their questions and explain things even further where necessary to relative understanding of processes, etc....this blueprint was a starting point and guidelines to build from.

Hope this helps a bit in answering your question about the blueprint.

We started with one developer and now have 2 plus a back up developer.

Yes I was a partner in this development and we both were as green as grass when we started.

Well rather weird about the partnership and skillsets.....

We partnered up 11 years ago and we have never met face to face.

We compliment each other in that we each have our strengths and when put together everything is covered....a very unusual situation given that we have never actually met. He is more into technical (servers, etc.) while I am more into design, copy writing, etc....and together there is a synergy.

Hope that answers your questions.

Cornell

[Dien Rice]

Originally Posted by Cornell

Hi Dien:

Thanks for mentioning the software.

My partner and I did develop the AthenaGold software.

When we started out we had a $15,000 budget....well....we have blown that right into outer space with costs that hit 6 figures 2 years ago....that is just developers fees by the way.

Hi Cornell,

Thanks again for further insights!

While I haven't "developed" software - I do own the complete and exclusive rights to a software product (which I don't sell any more).

What happened was, some time around the mid-2000s, I purchased the complete and exclusive rights to a software product, which was developed by someone else.

This company wanted to "streamline" their operations. So they were selling the complete and exclusive rights to a variety of their "non-core" products which they had developed.

The software product I purchased was software to backup your emails, if you were reading email on your computer (as opposed to reading email on a third-party website, such as Yahoo or Gmail).

Anyway, so I purchased the exclusive rights to the software, a couple existing websites to sell it (this was a product they had already been selling for a while), and so on. And I made some sales.

However, I wasn't really prepared for any support questions. Another thing is, I wasn't really prepared to "upgrade" the software as computer operating systems get upgraded, and so on. (Though the company I bought the software from did give me the contact details of the original programmer who had written the software, in case I wanted to hire him to upgrade it.)

With the benefit of hindsight, this purchase was a "mistake" for me, for the following reasons...

- I don't use email on my own computer - I use "web-based" email (specifically, I set everything up to use Gmail). That meant it was hard for me to "test" and use the software myself, so I could answer questions people had. Also, it meant I was less "passionate" about the software, too (since I wasn't even using it myself).

- I didn't have any kind of "support" set up. Because I wasn't really using the software myself, I wasn't even well-equipped to do the "support" myself, since I never really got to know the software very well.

Anyway, in the end, if people had problems, I gave them a refund.

I don't know if I broke even on this purchase. I think I probably made a small loss on this particular "venture". (For someone else, who was better positioned than I was to profit from it, they probably would have made a good profit. It wasn't quite right for me, for the above reasons, I realize now with the benefit of hindsight!)

How much should you charge for your product? If your product will probably need some kind of support, you should definitely factor that "cost" in, when you determine the price!

Let's say you sell software at $20 to 1000 people, or sell it at $200 to 100 people.

In both cases, you make $20,000. So they're the same, right?

Actually, no. The reason why is because in the first case, you need to provide support/customer service to 10 times as many people. So your "support/customer service costs" will probably be 10 times as high! (By "costs" I'm also including your costs in your time, not only regarding cash...)

Okay... I think I can slip down off the soap box for now...

By the way, here are a couple interesting articles on pricing...

This article says that pricing, in their experience, is completely "elastic" - that is, you'll sell just as much (in terms of dollars) no matter what you price you sell your product at... (This is specifically about games software.)

How Valve experiments with the economics of video games
http://www.geekwire.com/2011/experim...es-gabe-newell

This other article talks about a different experience. In this case, by doubling his price, he actually sold 10 times as much! This is for a "productivity" app product...

(The reason he sold more is because there often seems to be a relationship between the price and the "perceived value" of a product... The higher the price, in this case, the higher the "perceived value" was for the customer, so they wanted it more.)

How I doubled the price of my software product – and sold ten times as many copies.
http://www.startupproject.org/2011/06/price/

I thought these were interesting... And it relates to the issue of "price"...!

Best wishes!

Dien

Hi Ankesh,

Brilliant insights.
I like your take on being a "non-technical" founder lol
And hey BS'ng your way through technical talk is RAMPANT in great entrepreneurs. So you are keeping good company. Even though you did not know how to create the tech you wanted. You "Did it Anyways"

Learning Code:
Thanks for the links on where to learn coding. I think it helps to at least attempt to learn so you can "get the technical lingo down enough to communicate. So those are great resources.

Team Building:
Your step by step team building insights below warrant there own article. Very valuable. I usually look for these Yearly,Quarterly,monthly and daily rhythm when looking at start ups. Most DO NOT have these systems in place and suffer greatly in all areas as a result.

Even if you don't have a team. Every person needs to have this rhythm in their lives. Even if the team is just you/ imaginary

I appreciate the details you shared.

Thanks Ankesh

Originally Posted by Ankesh

Thanks Duane

I can't create the tech I want. That makes me a non-technical founder. Over the years however, I've learnt how to talk with technical folks to get the problems solved. I can bs my way in technical talk

(I've tried learning programming on my own a couple of times before but haven't followed through. Maybe this time, it'll be different with udacity.com and codeyear.com...)

My team... we have an office. But we also have a couple of folks working remotely. (We are a team of 6 people right now.) Given a choice, I would always prefer a single office space. Keeps folks more accountable. But I go where the awesome talent is. And so, we do hire remotely too.

To keep things moving well with remote workers, you need to: have a lot better documentation. Wireframes and screen shots and explanations. With people in the office itself, napkin plans also work. Because the feedback is more constant. But remote workers need more details to avoid communication gaps.

Feedback and communication. This is what is important. I get my remote employees to talk with everyone on the team. And not just talk with me or a project manager. This makes them feel involved. Makes them learn and share with other folks. Will be planning a week long get together for the entire team too - but haven't done that yet.

1. Weekly team conferences. For people who are remote, can join in via skype.

2. Get everyone to talk with everyone. No project manager handles communication stuff.

3. Face time is pretty important. So once a year, getting everyone under one roof would help a lot.

4. Sharing of ideas and knowledge and new stuff. Having a bi-weekly employee email is awesome.

5. Accountability. 6 monthly reviews. Weekly task lists. Daily i-did-this updates.

Hi Cornell,

Thank you for the detailed response about your Blueprint Process.

This more than answered my question of Blueprints. I can also see how this Book approach can be used in Project and Business creation. Especially if you have NOT done something before.

I see you used the "Multiple View-Point" Mindset to see the target from the other players perspective. It's a rarely utilized skill-set, at least from some of the people I meet.

Somebody once said "The hardest thing to Do is to ESCAPE your Point of View." Actually I just remembered it was Dr. Michael Hewitt-Gleeson quoting Edward De Bono who I believe coined the phrase "lateral thinking"

Team:

So you and your partner were "Green as Grass"..and you didn't let that stop you from creating your software project. Again like Ankesh you "Did it Anyways"

You NEVER met your partner face to face??? I think T.W had a thread going on the value of face to face meetings. Hmmm

Hmmm (tapping fingers on my desk)
..
...

Hmmmm (still tapping)

O.K Well I know you've shared a lot already BUT (voice in my head says "Do it Anyways)... I HAVE TO ASK....

WHAT THE HECK IS THE STORY THERE???
How do you form an 11 year "profitable" without meeting face to face?

I mean we've all heard the horror stories of partnerships yet yours (11 years) seems to have worked out. Aside from complimentary skills

#1) how did you meet and what made you say "yes"?. Did you meet on a forum?

#2) What made you both say "yes"?

#3) Why do you think it lasted so long?

Thanks for all of what you have shared Cornell. You, Ankesh, Dien have given hope to us "Low-tech's"

Duane (Oprah has nothing on me) Adolph

Originally Posted by Cornell

Hi Duane:

How did I learn )

I didn't really.

I just approached it as describing how I saw the software working and interacting with the user and within itself....I sat in 3 different situations...1 as the visitor, 1 as the web site owner, and 1 as the developer. I knew what I wanted the software to do so in my mind I went through each step a visitor to the site would go through in using the site. As the site owner I looked at what I would have to do to set each and every step up to make it all work. And as the developer - can I understand what his guy is trying to tell me.

To answer your questions this is going to be a long post and I may have to spread it over 2 posts.

To give an example I'll have to use our software...it is web site building, content management, etc.

Just like writing a book I started with an overview of what I wanted the software to be able to do and its purpose.

Then I sectioned it off into sections such as templates, graphics, affiliates, products, forums, blogs, eCommerce, etc.

Then I sub headed each section...for example templates...design, functionality, editing, graphics, WYSISYG editor, etc.

Then I simply described my vision of each and the interaction that I felt was needed and also added more sub-sub headings as needed under each sub heading.

Then for each subheading I did a summary, and again at the end of each section a summary.

This sounds rather simple but actually it is quite complex as if you don't lay it out exactly the developer can only second guess what you really want and also cost a lot of money if they have to redo things.

Just a quick example...let's take something relatively simple that everyone has some experience with...shopping cart...


Section: eCommerce

Sub Headings: Display, Checkout, Continue Shopping,Taxes, Shipping, Carriers, Payment Gateways, Special Codes, emails,...and several more and none in a specific order here.

So under the Sub Heading 'Payment Gateways' it would be something like this:

Software must be able to interact with api gateways to process credit card purchases (ie: Authorizenet), third party gateways (ie: PayPal), self testing software gateway.

Software must provide option of choice for the 4 default api gateways with integration into these api's and configuration area as required by each by the user. After configuring by the user the software must apply the configuration in the install and provide encrypted setting of same. Api's to be obtained by developer from gateway's sites.

Software must provide third party section to accomodate system such as PayPal with a configuring area to enter users PayPal information and then apply configuration in the install and provide encrypted setting of same. Developers must program to interact with PayPal as per info obtained from PayPal. This configuration must also include optional use of PayPal sandbox with user able to select that mode and also turn off that mode. Software must recognize when sandbox setting is enabled.

Self testing must be written by the developer to allow the use of false credit card info to do a false system check by the user such that the shopping cart is completely functional such that when an order is purchased while self testing is enabled, the the cart processes the payment throughout the system including the sending of emails to the user, the site owner, and other systems within the software that are tied into the type of purchase according to settings for the different classes/types of products, shipping settings, carrier settings, etc. This system will over ride all other settings for the payment gateways while it is marked to be in use. When canceled then the selected and configured gateways will then be applied to the shopping cart.

Summary:

This section should be accessible by a link from the eCommerce main page.

All options must be on the same page with headings clearly marked. Within each section for each heading there must be a configuration button to open a window where user can input necessary info and then an apply button to apply his configuration to the software. Window will close when apply button is clicked and the information has been added to the software and successfully encrypted.

A secondary radio button is to be available in each section to be marked by the user to indicate which of the configurations are to be applied to the cart and when selected the software will implement these as options at the time of selection of the checkout button on the shopping cart with display as noted in the Sub Heading section under eCommerce named 'Display'.

It is to be noted that only one default api gateway can be selected at any given time and if more than one is selected software must provide a warning screen that selection is incorrect and that only one can be checked for use.

I should also be noted that third party gateways can be used in addition to the default api gateway.

It should be noted that when the self test is activated that at the completion of a test of the shopping cart a popup warning be displayed on the screen to remind the user to return and disable the self test when finished. Secondarily the software will send an email to the site owner if the shopping cart sits idle for a period of 15 minutes while the software is in self testing mode with a warning that the self testing mode is still activated. This process will continue in 15 minute intervals until the self testing has be turned off.

It should be noted that when sandbox is selected in the PAyPal configuration and is not deactivated after a period of 30 minutes an email is to be sent to the owner notifying owner that sandbox has not been deactivated. This process will continue in 30 minute intervals until the sandbox has been deactivated.

Just a bit of an example...shortened just to give an idea of what was needed....some of the descriptions above would have been even more expanded as needed.

We had many conferences with the developers on the blueprint to clarify and answer their questions and explain things even further where necessary to relative understanding of processes, etc....this blueprint was a starting point and guidelines to build from.

Hope this helps a bit in answering your question about the blueprint.

We started with one developer and now have 2 plus a back up developer.

Yes I was a partner in this development and we both were as green as grass when we started.

Well rather weird about the partnership and skillsets.....

We partnered up 11 years ago and we have never met face to face.

We compliment each other in that we each have our strengths and when put together everything is covered....a very unusual situation given that we have never actually met. He is more into technical (servers, etc.) while I am more into design, copy writing, etc....and together there is a synergy.

Hope that answers your questions.

Cornell

Originally Posted by Duane Adolph

Hi Cornell,

You NEVER met your partner face to face??? I think T.W had a thread going on the value of face to face meetings. Hmmm

Hmmm (tapping fingers on my desk)
..
...

Hmmmm (still tapping)

O.K Well I know you've shared a lot already BUT (voice in my head says "Do it Anyways)... I HAVE TO ASK....

WHAT THE HECK IS THE STORY THERE???
How do you form an 11 year "profitable" without meeting face to face?

I mean we've all heard the horror stories of partnerships yet yours (11 years) seems to have worked out. Aside from complimentary skills

#1) how did you meet and what made you say "yes"?. Did you meet on a forum?

#2) What made you both say "yes"?

#3) Why do you think it lasted so long?

Hi Duane:

You are really wanting me to come clean aren't you )

Short background about how we met....my ex died and I became a single parent...loads (and I mean loads) of legal expenses in keeping custody of kids away from a couple of members of her family as we weren't together at the time (they were after the estate more than wanting the kids - even went so far as to producing a fake will), plus many, many other expenses in the transition. As a result I was selling off rights to a couple of products to raise money.

My future partner bought one of the rights which meant quite a bit of communication.

It so happened at the time B Myers had recently sold off the software we were using to power our sites and the new owner was throwing the screws to us.

We talked about it and in the conversation we joked we should get our own script done to power just our own sites. And out of that we decided to do it.

When it was partially done I showed it to another person who had been using the same software we had been using to power the sites....he loved it and said we should not keep it to ourselves.

We talked it over and showed it to a couple of more people and they had the same response...and from there it went from development for personal use to development for commercial use.

As I previously said there was a synergy and we both brought to the table complimentary skills. We had discussed what we would need to do the task and it worked out that where one was weak the other was strong.

Here is a kicker for you....our developers....we have never spoken person to person, or met our developers either. They understand English and read and write it proficiently, but as they don't speak it well they requested not to talk in person....so this relationship has endured also for just about 11 years.

Why has it lasted so long? Hmmmm.....

Mutual respect....courtesy....open communication....all things discussed with open minds (no one is ever right or wrong)....willingness to bend if the other has a better way of doing something....pretty much a 50/50 give and take situation.

Pep talks when needed, etc.. We (including developers) have pretty much become an extended family...we know when our kids are having problems or we are having personal problems...we know when the developers family is experiencing upheavals, or illness, or loss....as I said just like an extended family.

As an example of the 50/50....say if a client needs a mod to the software to accomplish something specifically related to their needs.....whomever the request came to initially that person would look at it and decide if and how it could be done from their point of view...then that input would be passed to the other with the other inputting his ideas of how and if it could be implemented...a couple of emails back and forth and if needed a voice to voice discussion of it.

Then, because as you know we aren't coders.....we would send off to the developers what was needed, our ideas on how it should / could be implemented, and asking for their input and ideas regarding the mod needed. I can't remember one time where the developers came back with a no we can't do it.....must comment here that our ideas of how it could work don't always fly but the developers have always found a way to implement it.

Has it been completely smooth sailing ...no...and I hate to admit it but it was me who lost their cool on 3 occasions....but all was worked out within a couple of hours if not minutes.

That's about it in a nutshell.

Cornell

Hi Cornell

THANKS for "coming clean"

I appreciate your candidness. It's sounds like quite the ride. Full of ups and downs and drama.

Interesting to hear that you never spoke with the developers either.

I enjoyed and learned from your detailed posts. If you have not already thought about it...you should write a book...starting with these posts.

Thanks again Cornell

Originally Posted by Cornell

Hi Duane:

You are really wanting me to come clean aren't you )

Short background about how we met....my ex died and I became a single parent...loads (and I mean loads) of legal expenses in keeping custody of kids away from a couple of members of her family as we weren't together at the time (they were after the estate more than wanting the kids - even went so far as to producing a fake will), plus many, many other expenses in the transition. As a result I was selling off rights to a couple of products to raise money.

My future partner bought one of the rights which meant quite a bit of communication.

It so happened at the time B Myers had recently sold off the software we were using to power our sites and the new owner was throwing the screws to us.

We talked about it and in the conversation we joked we should get our own script done to power just our own sites. And out of that we decided to do it.

When it was partially done I showed it to another person who had been using the same software we had been using to power the sites....he loved it and said we should not keep it to ourselves.

We talked it over and showed it to a couple of more people and they had the same response...and from there it went from development for personal use to development for commercial use.

As I previously said there was a synergy and we both brought to the table complimentary skills. We had discussed what we would need to do the task and it worked out that where one was weak the other was strong.

Here is a kicker for you....our developers....we have never spoken person to person, or met our developers either. They understand English and read and write it proficiently, but as they don't speak it well they requested not to talk in person....so this relationship has endured also for just about 11 years.

Why has it lasted so long? Hmmmm.....

Mutual respect....courtesy....open communication....all things discussed with open minds (no one is ever right or wrong)....willingness to bend if the other has a better way of doing something....pretty much a 50/50 give and take situation.

Pep talks when needed, etc.. We (including developers) have pretty much become an extended family...we know when our kids are having problems or we are having personal problems...we know when the developers family is experiencing upheavals, or illness, or loss....as I said just like an extended family.

As an example of the 50/50....say if a client needs a mod to the software to accomplish something specifically related to their needs.....whomever the request came to initially that person would look at it and decide if and how it could be done from their point of view...then that input would be passed to the other with the other inputting his ideas of how and if it could be implemented...a couple of emails back and forth and if needed a voice to voice discussion of it.

Then, because as you know we aren't coders.....we would send off to the developers what was needed, our ideas on how it should / could be implemented, and asking for their input and ideas regarding the mod needed. I can't remember one time where the developers came back with a no we can't do it.....must comment here that our ideas of how it could work don't always fly but the developers have always found a way to implement it.

Has it been completely smooth sailing ...no...and I hate to admit it but it was me who lost their cool on 3 occasions....but all was worked out within a couple of hours if not minutes.

That's about it in a nutshell.

Cornell