So Carl, one thing I wanted to ask you was, if I'm a solo entrepreneur,
how would I go about finding an engineer to help me work on these projects?
>> Finding an engineer can come in a myriad of different ways.
You can always place an ad on something like Craigslist.
There's the tried and true LinkedIn, or even a site like Stack Overflow does
a really good job of representing developers.
Of course, if you're a hackathon attendee,
maybe you'll be assigned a team mate.
So, that might be just a serendipitous meeting.
Of course, you can always go rummaging around in cafes or
coffee shops and looking for people with laptops as well.
>> Okay.
And how would I go about choosing an engineer if I had two, three people
answer my Craigslist ad, how would I go about choosing who I want to work with?
>> Choosing who you work with is,
something I think that's dependant on what your end goal is.
If you're looking for,
maybe a web-based project, then you want to focus on the specific skill set.
So you're looking for somebody with a background in HTML/CSS and JavaScript.
If you're looking to go full-fledged mobile, maybe native experience.
Then you're looking for somebody with iOS development experience
with Objective C or Swift, or even in branching out into Android as well,
you will need somebody who has, experience with that SDK and with Java.
>> How would I go about working with an engineer?
When I've found one that I want to work with,
how do I go about actually asking them for help?
How do I go about getting use out of them.
>> Sure.
>From my perspective,
I like to get involved as earlier in the project life cycle as I can.
Getting me involved means, showing me a lot of the design work that's happening.
Explaining a lot of your thinking.
As your feature set is evolving through the design process.
>> Mm-hm.
>> I am going to want to understand what you're end goals are.
I'm going to want to understand what you believe is the minimum viable product.
And I'm going to want to understand what your longer term goals are for
your project.
>> Right, and so naturally, you would want to be involved as early as possible
and that would be the way to get the most use out of you, but
there's also this pull of, if I'm the sole entrepreneur,
I might have a limited budget.
I might not be able to pay you for the entire life of the project.
>> Yeah.
>> So in that case,
would it make more sense to just take you on at the end when I can actually,
just ask you to build the app and that's all I've got money for?
>> Well, the app experience can be as big or as small as you want to make it.
So bringing me on at the end would be okay, but
I think we lose a lot of the context.
A lot of the decisions that are made through the prototyping phase,
through the design phases, I think can inform upon how the product is built.
So again. And
I would want to come on a little bit earlier in the product life cycle.
Now that said, if you do leave it towards the end,
then you're going to want to have a really well-defined spec,
a really fleshed out idea of what you want build.
And then you're going to want to be able to talk to that engineer
about the budget.
>> Mm-hm.
>> You're going to want to talk about the feature set that you're asking them
to build, and
then you're also going to want to to set some realistic delivery dates.
>> Right.
And of course, one common thing is if I'm an entrepreneur who doesn't
have a background in coding, then what's going to happen is,
I might set these unrealistically.
It might not occur to me that thing X is going to
take a lot longer to build than thing Y.
I might assume that they're going to take the same amount of time and
set, give you these delivery dates that are for
this one, totally doable and this one, way unrealistic.
>> Yep, and that's why I like to get engaged to a project early on, so
that I can set some realistic expectations as well.
I do think that it's important to involve your developers in that regards,
so that we don't end up with something like feature creep or
scope creep within the project.
It's very easy to become quite enamored with a particular interaction or
a set of screens, that maybe are not core integral to the experience.
>> Mm-hm.
>> But we believe in launching and iterating.
So, striving towards that, I mean,
viability, and then involving the developer early on will
help you establish what that looks like, and help you craft a plan of execution.
>> Perfect, thank you very much.
>> You're welcome.