At Gong, we’re proud to have a guild, too.

As a front-end developer at Gong, in this post, I’ll focus specifically on our front-end guild, but many of the things I share here can also be applied to guilds for back-end developers, mobile, DevOps, and more.

This post will shed some light on why to start a guild at your company and how to actually do so in a way that has an impact on the company and the people that are part of it.

I start out with some background, followed by concrete steps we’ve taken (and you can, too):

1. Terms and background
2. Setting goals for the guild
3. The guild’s structure and processes
4. Creating a roadmap for the guild
5. Getting buy-in and support from management
6. What’s next for us?

Terms and background

What is a guild?

According to dictionary.com, a guild is:

• An organization of persons with related interests, goals, etc., especially one formed for mutual aid or protection.
• Any of various medieval associations, as of merchants or artisans, organized to maintain standards and to protect the interests of its members, and that sometimes constituted a local governing body.
• Botany. a group of plants, as parasites, having a similar habit of growth and nutrition.

Even without getting into the tech terminology, we can see that a guild is a group of people with something in common and the desire to improve together.

It works in nature with plants and parasites, so why shouldn’t it work at a company?

One of the first (or maybe even the first) tech companies to take this seriously and create a guild was Spotify. (You can read about it here.)

The idea snowballed, inspiring other companies around the world.

If the biggest and brightest companies are doing it, you should, too, right? Well, not so fast… Building and getting value out of a guild takes work, so, like everything, you should be able to identify a real “why” for your guild. Otherwise, it’s likely to fall flat on its face or even become a bottleneck — exactly the opposite of what’s supposed to happen.

So, why should you start a guild?

There are lots of reasons to start and have a guild. In a moment, I’ll share the reasons behind ours, here at Gong.

First, however, a word on how R&D is structured at Gong: Our R&D team is organized into pods, a decision made by the company leadership to make our work and delivery of Gong products faster and more streamlined. (Read more about our pods and other aspects of our unique culture in this post by Ohad Parush, our EVP of R&D.) At other companies, like Spotify, pods are called squads, but the idea is the same.

A pod or squad, is, according to Cambridge Dictionary, “a small group of people trained to work together as a unit.” In high-tech, this usually refers to a self-sufficient unit that comprises everything it needs to work fast and smoothly.

Each pod at Gong consists of a team lead, product manager, product designer, content writer, and developers (back-end, front-end, cloud experts, and more depending on the specific needs).

The advantage of pods is that they have the agility and they’re totally focused on the product (unlike, for example, infrastructure teams, which can become a bottleneck and are often too far removed from the product). The challenge, however, is that a team made up of pods lacks owners for the infrastructure-related tasks and other cross-company processes.

Since each pod is responsible for a product or specific, significant element of our SaaS product, what we need is someone who can take ownership of cross-company tasks.

That’s where the guild comes in.

The guild might be responsible for:

• Infrastructure tasks
• Knowledge sharing
• Onboarding new developers
• Bringing architecture decisions to the table and making the final decision
• Work directly with the company’s management
• …and at least 10 other things.

Before creating and assigning responsibilities, however, it’s most important to determine, as a team, your main pain points and, therefore, goals for the guild.

To come up with goals for the Gong guild (try saying that ten times fast…), we started by turning to the crowd wisdom of the developers in the guild.

We created a poll with around 15 questions divided by subject (e.g., delivery, quality, knowledge, guild structure). We structured the poll in a way that would enable us to actually define and measure the progress down the road, as well as get clear directions for what to handle first.

After the poll, we split into 4 roundtables, each with about 5–7 participants to enable open discussion. Each table was responsible for a different area and was led by a “table lead,” who led the discussion and gathered the ideas and common thoughts.

The conclusions from the poll and roundtables helped us zero in on the following top priorities at Gong:

1. Design system upgrades and more tests
2. Delivery time improvements (specifically improving the speed of the local environment)
3. Knowledge sharing (specifically more lectures on specific subjects we encounter every day as developers at Gong)
4. The guild’s agenda, structure, and “titles”

In other words, we whittled it down from over 10 “big ideas” that we thought we should be responsible for to 4 areas that were super specific and focused. The rest (onboarding, recruiting, and more), while important, aren’t as high priority and central, based on the crowd's wisdom.

With that list in hand, we would have an easier time defining goals that actually make an impact.

First, though, let’s jump to #4 on that list: The guild’s agenda, structure, and “titles” because it sets the foundation for everything the guild can, and can’t, do.

Guild leadership, structure, and processes

There are lots of different ways to divide up tasks and responsibilities among members of a guild. And it’s easy to fall in love with other companies’ guild roles and titles: guild ninja, guild moderator, guild magician, guild [something strange]… Yup, those are real titles that companies use.

But it comes back to that central “why”: Why do you want a guild? What do you really need?

At Gong we used the data from the polls and roundtables we did (plus learnings from prior guild meetings) to find the right titles and structure for us (and it’s still a work in progress…):

Guild Master: This person leads the guild. At Gong, the guild master is a very experienced developer who spends around one day a week on guild tasks and management. He isn’t expected to do all the guild tasks himself or split them with one other person (that was one of the mistakes we made before the roundtables…). Instead, he’s responsible for delegating tasks in a smart and efficient way. (At some companies, the guild master is a full-time job, and that individual is responsible for leading and executing the guild’s tasks. That’s not the case at Gong.)

Guild Leads: We have a few guild leads. Each one is the owner of a big goal or pain point and is responsible for making it happen and working to eliminate any stumbling blocks that may be standing in the way. They spend a couple of hours a week (tops) on their focus area, and they often work closely with the guild master, but not always. Some examples of guild leads are: meeting agenda lead, knowledge-sharing lead, design system lead, testing lead, and more based on actual needs we have, rather than guesses or feelings.

Besides the titles, we also came up with specific guidelines for guild meetings, so they’re as effective as possible:

• Keep meetings short and sweet so participants can get as much as possible out of them
• Put together an agenda that combines new stuff people are working on with new things people want to present and teach (short sessions only — longer lectures are scheduled outside of the guild meetings)
• Schedule no more than two 1-hour meetings per month — everyone’s time is valuable and we care about respecting that; if we cover everything before the hour is up, we end early
• Leave a 7–10 minute slot at the end for participants to ask anything they want

Outside the guild meeting, we do lots of offline things, too, such as:

• Huddles, an open forum where team members can present or suggest new architecture, ideas, or libraries and lead/participate in a discussion about it to decide the next steps
• Lectures by people both inside and outside Gong to enrich knowledge among the front-end developer team
• Slack channel for offline questions/consulting, meetups, new posts, and more
• Guild contributors — Each quarter, the leads of each pod provide the names of developers who are willing to volunteer for the guild and participate in infrastructure tasks for 1–2 weeks (It’s actually really fun, I swear!)

And now: The roadmap!

As I mentioned at the beginning, besides the guild’s main activities and priorities, we’re also responsible for infrastructure and cross-company tasks. So, once we set our goals (and considered other responsibilities), we put together the roadmap.

The roadmap is a crucial part of making sure that the guild remains focused and being able to measure its effectiveness. We created a task roadmap with the priorities and sub-tasks for the next two quarters and presented it to our tech leaders (EVP of R&D, group leads, etc.) to get buy-in and time to work on it beyond the normal product tasks each developer already has.

At Gong, we chose 3 main goals to drive the roadmap:

• Design system
• Testing our components
• Local environment and faster deployment process

(And one optional 4th goal for the future: TypeScript)

I won’t get into the sub-tasks and timelines here, but with these goals clearly defined, we could then start working and easily navigate and divide up tasks among developers.

Getting management involved

This was the point at which it made sense to get management involved.

Once we had a rough roadmap in place, we scheduled a couple of meetings with our leadership to present our process, goals, pain points, and final roadmap and ensure alignment on how we plan to carry it out, how much time we can allocate towards guild tasks, and overall expectations.

By working through the details with the company management, we were able to get more buy-in. After all, when people are involved in decision-making, rather than having it dropped on them, it’s more likely to succeed, even if it means compromising a bit. And from our side, that support from the leadership gave us the motivation and momentum we needed to get things moving.

(It’s worth mentioning that we got our EVP R&D involved from the very start to ensure full alignment between guild goals and company goals.)

What’s next?

When the front-end guild was started at Gong around 2–3 years ago, it was just 5 developers. Since then it’s grown significantly, making it clear that we needed to find a way to operate and scale more sustainably and intentionally. About 6 months ago, we started all the processes I’ve described here.

Thanks to our roadmap and a clearer structure, there’s more clarity surrounding the guild — what it does, how it works, etc.

Still, there are many challenges ahead, including:

• Boosting the engagement of the developers in the guild
• Proving to ourselves and to company management that we actually make an impact (with facts and figures to back it up)
• …and lots of other challenges we don’t even know about yet.

As Ohad wrote in his post about Gong’s culture, we love our developers and our guild, but we’re not in love with our guild: we’re constantly looking to learn from other developers and guilds at other companies (shoutout to Daniel from Outbrain!) so we can make changes and improve the way we work.

As the guild, we constantly remind ourselves that our role is to solve the real pains Gong developers have — not to invent stuff that doesn’t exist and that might distract us from what really matters.

We may have a long way to go, but we think we’re off to an exciting and promising start…

Special thanks to all the people who were involved in the process we started.

Yasmin, Moshiko, Ran, Shmulik, Valentin, Eli, Amir, and the rest of the FE Guild at Gong!

Does your company have a guild? Do you have questions about our guild or thoughts about guilds in general? Drop them in the comments or reach out! I’d love to hear from you and bring new ideas to our next meeting or huddle.

Want to be part of a kickass team that writes awesome code by day and geeks out on guild stuff, erm, also by day? We’re hiring! Check out our open positions here.

Building an Impactful Guild: How We’re Doing It At Gong was originally published in Gong Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Finally, we got to the last post explaining about the future that’s coming for RN architecture.

We discussed the current structure until now and it is time to talk about the stuff that was not the perfect choice, looking backward as React team leader on Facebook at this time mentioned in her blog post

Some of the main disadvantages of the structure of the current architecture are =>

• There are two realms: JS and Native which are not really aware of each other and do not share the same memory
• The communication is async through the bridge between the two realms but it also means no guarantee the data will get to the other side in 100% or in the time we want
• It is slow to transfer large chunks of data. Since the memory is not shared, all the data passed between js and native is a new copy
• No way to update the UI in a sync way. Let's say I have a FlatList with a huge amount of data the is loaded when I scroll, the screen might flicker in some edge cases when there was a UI interaction but the data hasn’t got back yet to be shown
• The library repo is HUGE. It makes the library heavier and also making it slower to contribute code from outside or release new fixes

Don’t get them wrong, Facebook is using React Native by themselves for the Marketplace app, Ads app and more which servers millions of daily users. In addition, some well-known companies like Wix, Bloomberg, Tesla, Zynga and much more using RN in production with the current architecture.

But all of the above companies and especially Facebook got to a point where they understood that if they want to make a better native experience and better developer experience they have to do a huge move and change and this is exactly what they are in a process of doing (part of it is already completed)

They decided to solve all those issues mentioned as disadvantages above.

So if that was the previous architecture structure =>

This will be the new one =>

Now, let me explain about all the new words you see here: JSI, Fabric, Turbo Modules, and CodeGen.

I will do it in the same way I did in my last post. First -> Fundamental terms and Second -> App launch flow with the new structure and terms.

1. JSI (Will replace the Bridge) — Its purpose is to make the JS and Native are aware of each other. There won’t be any need to serialize JSON through the bridge and even more than that — there won’t be a bridge! It will allow to expose native object as js objects and vice-versa. It will also expose an API for synchronous calling on this object on both sides. Actually, all the rest of the architecture will be built on top of that (Fabric, Turbo Modules which will be explained next).
2. Fabric — the new name for the UIManager which will be responsible for the native side. The biggest difference now that instead of communicating the JS side by the bridge, it will expose its native function using the JSI so the JS side and vice-versa can communication directly those ref functions. Better and efficient performance and passing data between sides.
3. Turbo Modules. Remember the native modules from the last post? Text, Image, View. So their new name is Turbo Modules. They have the same purpose but implemented and acting differently. First, they are lazy-loaded (only when the app needs them) comparing to loading all of them on the launch time. In addition, they are also exposed using the JSI so JS holds a ref to use them on the React Native JS lib side. Result => better performance especially on launch time.
4. CodeGen — Suppose to make the JS side a Single Source Of Truth. Can let you create static types of the js so the native side (Fabric and Turbo Modules) will be aware to them and avoid validating the data each time => better performance and less place for mistakes when passing data.
5. Lean Core — A change in React native repository structure. The purpose is to make the lib lighter and help the community resolve more pull requests faster than before. Facebook splits some of its parts to an external repo. It is already a process in progress that you can follow in their Github here. This is how they show it =>

BTW — here is an example of something you can try on your chrome browser which is the inspiration for how the JSI works and exposes objects =>

As promised, I will now go over the flow from the previous post and will show the differences. The biggest difference is that there is no Bridge anymore.

1. User clicks on the app icon
2. Fabric loads the native side (no native modules)
3. It tells the JS thread that it is ready and now the JS side loads all the main.bundle.js which contains all js and react logic + components
4. JS called through the ref native function (the one that was exposed as an object using the JSI API) to Fabric and the shadow node creates the tree as before
5. Yoga does the layout calculation converting from flexbox-based style to host layout
6. Fabric does its thing and shows the UI =>

To wrap up the flow, we do almost the same but without the bridge and now we can have better performance, we can do stuff in a sync way and even prioritize the sync actions on UI. The launch time will also be better and the app size will be smaller.

So..when can I use all this awesome stuff???

You can follow all the updates in threads that Facebook created in their Github here:

1. JSI
2. Fabric
3. Turbo Modules
4. Lean Core
5. CodeGen

Generally, most of the changes will be done gradually and will hopefully be released in Q4 2019 or Q1 2020.

Finally, we got to the end of the posts about Project Fabric. It took me some effort to collect all those pieces of information to get a better understanding of this new structure.

I will be happy to get some Claps and if you also want to follow me on twitter to see the slides and lectures I started giving about it you are welcome to follow here

Feedbacks are also welcome! Thanks for reading (:

My Twitter: chenosfeldman

My LinkedIn: Chen Feldman

P.S — here is some little part of links I read and watched as part of the process and recommend you to try to sharpen your understanding. (I give credits to all of them for giving me great material to read and watch)=>

• Latest RN news from Core Team- https://facebook.github.io/react-native/blog/
• Parashuram post about the new architecture http://blog.nparashuram.com/2019/01/react-natives-new-architecture-glossary.html
• Pharam new 2019 lecture React Amsterdam — https://www.youtube.com/watch?v=NCLkLCvpwm4
• https://levelup.gitconnected.com/wait-what-happens-when-my-react-native-application-starts-an-in-depth-look-inside-react-native-5f306ef3250f
• Layout engine explnation — https://www.freecodecamp.org/news/how-react-native-constructs-app-layouts-and-how-fabric-is-about-to-change-it-dd4cb510d055/
• Four parts article about the new architecture by Lorenzo from Formidable (part 1 here links to the others)— https://formidable.com/blog/2019/react-codegen-part-1/
• FB State of React Q4 2018 by Sophie Alpert from FB team at this time — http://facebook.github.io/react-native/blog/2018/06/14/state-of-react-native-2018

Credits to : Ronen Mars, Nick Ribal or frenkel and Irad for helping to finalize the post’s content

My lectures about this subject — upload here soon

• React Next 2019 (English) — https://youtu.be/_IiDHmAPH28
• Reversim 2019 (Hebrew) — https://youtu.be/2eZ4G-loZkY
• Podcast episode (Hebrew) — https://www.ranlevi.com/2019/07/23/osim_software_react_native_bridge/

In the previous post, I explained the way the bridge lets JS thread communicate with the Native thread and vice-versa.

In this post, I am going to break the process of opening the React Native app from the moment you click on the app icon to the moment the app opens to small parts and explain each relevant term inside it.

Let’s go!

In order to understand how RN creates the views in the background, I will need to explain to you some fundamental terms.

1. UIManager — Responsible on the native side. This is the main thread where the iOS/Android app is running. It has access to the UI which can be changed only by it.
2. JS Thread — Run all the bundled main.bundle.js file which contains all the logic of the app & the React Native behavior and components.
3. Shadow Node/Tree — Represent a tree of the mutable native side of the app. It supposes to help follow the UI changes inside the app (if it helps it has kind of the same relationship between the Virtual DOM and the DOM in ReactJS.
4. Yoga — Its job is to calculate the layout. It is a C engine created by Facebook that knows how to convert a flexbox-based layout into the native host layout system.

After you got some fundamentals lets take a flow of opening an app and I will describe what happens behind the scenes on each step =>

1. User click on the app logo
2. UIManager thread — loads all the native side and the native modules (remember? Text, Button, Image and much more..)
3. It tells the JS thread that it is ready and now the JS side loads all the main.bundle.js which contains all js and react logic + components
4. It sends a message thought the bridge (JSON message) that will tell the native side how to create the UI. It is important to mention that all the communication through the bridge is asynchronous and sent in batched action to avoid blocking the UI while it happens. Here is an example =>

5. The shadow thread gets the message and first, it creates the UI tree

6. From there it uses the Yoga layout engine to take all the current flexbox- based styles and convert it to native layout width, height, spacing..

7. Now the UIManager do its thing and show the UI on the screen like that =>

That’s it, those are the main steps that happen only when you lunch the app.

There are some great advantages by using this architecture in RN

• UI is not blocked -> User experience feels smoother
• No need to write native code — most of the code can be javascript using RN library
• Performance is getting closer to native
• Everything is done without you need to control it and fully understand it

But, where you can find advantages, you can always find some disadvantages and in the next post, I am going to explain about the new architecture which supposes to avoid them — Project Fabric.

I will be happy to get some Claps and if you also want to follow me on twitter to see the slides and lectures I started giving about it you are welcome to follow here

Feedbacks are also welcome! Thanks for reading (:

My lectures about this subject

• React Week NYC 2019 (English) — https://youtu.be/k1Y6C11QX5c
• React Next 2019 (English) — https://youtu.be/_IiDHmAPH28
• Reversim 2019 (Hebrew) — https://youtu.be/2eZ4G-loZkY
• Podcast episode (Hebrew) — https://www.ranlevi.com/2019/07/23/osim_software_react_native_bridge/

In the last couple of years, React Native became one of the most popular platforms for mobile apps development. It filled some of the gaps that some developers had while asking themselves: Should I develop a mobile app using native languages or a hybrid app using web development knowledge(JS, Html, CSS using Cordova or Ionic for example)?

Using RN requires a knowledge of web technologies like the above and also React experience since it’s mostly based on it and its mechanism. So with a little bit more effort than using libraries like Cordova and a lot less effort than writing code in two native languages: Swift & Kotlin, you get a middle ground which gives you a native-like experience by writing almost 100% javascript code.

While I am playing with some code, reading many posts and watching tons of videos on YouTube and learning about The Bridge, which is the current architecture of RN at least until version 0.60, I found some more and more material about a big change in this architecture. It’s called — Project Fabric

Those new materials are not 100% organized and do not contain enough real projects for example since it’s work in progress (WIP) by the Facebook React Native team and its contributors. To get the real image of the new architecture that actually starts to make sense, I had to read and watch the same materials 2–3 times, summarise them and try to read some of their WIP code.

I would not tell you it was an easy job, but for me, definitely a rewarding one. I learned so much from this process of diving into this code and decided to write a series of 3 posts to spread some more light on the current architecture & the future one.

These will be the posts

Part 1 (current) — Intro and what is this Bridge that everyone is talking about and what is the “magic” behind it?

Part 2 - How does the engine behind React Native works? Giving an example of flow.

Part 3- The advantages and disadvantages of the bridge and what is next? Project Fabric

Let's start this part by explaining where React Native stands compared to other options.

In the image above, I took part in the libraries you can use (of course that there are hundreds more) to develop a mobile app that you can upload to a store (App Store, Google Play..)

I would divide those platforms into three (right to left):

1. Native. It means you want to write your app using a native language like Swift for iOS or Kotlin for Android. You will defiantly get here the best performance and you will be able to get the most out of the device hardware and native APIs. But, it requires learning two different programming languages, maintaining two different repositories of projects and has probably a double amount of bugs and maybe even two different development teams.
2. Hybrid. If you are a web developer or have a team of web developers who are already familiar with JS, HTML, CSS and maybe some frontend lib (not required), you can take them and with some more steps using Cordova/Ionic make your website a mobile app or just develop a mobile app. Here we learn only one development stack and using only one team. But, we might pay in a limitation on the performance side, hardware limitations and other device abilities we want to access like : GeoFencing.
3. Native-Like (also kind of Hybrid in a way). This is the category where React Native stands in. You learn JS, HTML, CSS and using your web development team that might also know React lib or need to learn it. But now they can have a little higher learning curve than the Hybrid options. They learn to React Native lib and might need to open the project in some cases in XCode or Android Studio (IDEs for iOS and Android) but the code they write will be relevant to both iOS and Android platforms and in this case, there are fewer limitations than the Hybrid option. The performance will be almost like you wrote native code and you will be able to access hardware a lot easier if we are talking again about the example of GeoFencing as a use case.

Now that we understand where RN stands, let compare a case of using Cordova as a use case of Hybrid app between RN app

As you can see in the image above, the app which used Cordova is hosted as a web view inside a real native component called the UIView (in case of the example of iOS). Generally, it’s more like a browser inside a mobile app and everything is affected by that. If you want an example from the web dev world, it’s more similar to an iframe inside a web app.

The left side shows how it works in React Native. Each component in the RN Javascript library (Text, Button, Image..) has a corresponding native component written in the native language. So differently that most new RN developers think, it’s not compiling to native code, it’s mapped to a corresponding component in the native side.

When we write this part of code inside a render function of an RN component this way =>

Part of the pre-written native component will look like that behind the scenes =>

If we take iOS as an example, this is the inner code of a native module in RN =>

To summarise, the RN team already created and mapped all the native modules for you. What you need to do is just write what you love — javascript code using RN components and library. All the rest will be transparent to you as a developer and will work like a “magic”.

But you know, magic is not real (sorry Santa), especially in coding.

Now that we are ready to put our legs inside the water before we dive, let’s do it!

So it seems that you just write js code and it’s just working. Let me start explaining step by step how this architecture is built. The best place to start is the Bridge.

Each side has its own thread: JS and Native (that has more but we will talk about them later).

The thread can communicate with the bridge with JSON messages containing: module id, method id to use and data if needed. They are not aware of each other directly and do not share the same memory.

It’s like the message broker pattern. When you have backend services written in different languages, how will you communicate between them?

A queue is a great solution many people use. You send the queue JSON/XML message in an agreed format and each service knows how to read it and translate it to action on his side. So this queue is the Bridge.

This is an example of how the communication looks, a message is sent to the bridge. From creating new views and show on the screen + its styles to setting children on the mobile side and doing some actions =>

For the curious ones here, to see the bridge messages on the console, just put the following snippet into the index.<platform>.js file =>

Now we understand how it communicates and starting to break the magic.

• Calls js code from objective-c and vice-versa. RN uses JSCore which is more fit to iOS and already built-in there.
• JS Engine knows to convert JS to machine language and work much more efficiently.

Chrome, for example, uses V8 and this is not just luck that this one of the most popular and fastest browsers.

This is one of the reasons that if you have an android app it takes more time to load since it’s bundling JSCore to its project.

But here is a spoiler announcement from the last ChainReact conference by Mark Horowitz. Hermes which is a JS Engine ideal for RN is available to use since version 0.60.2

Now that we broke some of the magic of the Bridge, we are ready to deep dive and give an example flow of opening an RN app and explain how the JS and Native side are actually communicating with the help of the bridge and much more interesting architecture parts in the next post.

• Credits to unsplash.com and Freepik.com for part of the image resources (relevant for all 3 parts)

I will be happy to get some Claps and if you also want to follow me on twitter to see the slides and lectures I started giving about it you are welcome to follow here

Feedbacks are also welcome! Thanks for reading (:

My lectures about this subject

• React Week NYC 2019 (English) — https://youtu.be/k1Y6C11QX5c
• React Next 2019 (English) — https://youtu.be/_IiDHmAPH28
• Reversim 2019 (Hebrew) — https://youtu.be/2eZ4G-loZkY
• Podcast episode (Hebrew) — https://www.ranlevi.com/2019/07/23/osim_software_react_native_bridge/

React Native — A Bridge To Project Fabric — Part 1 was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

For a long time I wanted to create a React lecture but could never find the right time and courage for that.

When I almost started I said to myself : “Who do you think you are? You are not ready yet dude..”

But Luckily , I told some people about it some spontaneous calls and meetings and some of them gave me some great tips and made me feel I can do it.

Feeling you can is not enough , but you also need your first early adopter for presenting the lecture and get valuable feedbacks.

Two months ago, Omri Bitan(a great friend and the founder of UpStream Accelerator) , approached me and asked me to do a React lecture for the 5 startups there.

Of course I said yes and from there the clock started to tick and I did not have a choice but to be efficient and just do it!

It is truly important for me that others can learn from my processes and make their life easier if they are also trying to do the same thing.

I documented most of the processes from the start,

I used the documentation in order to build a todo list

hopefully it could help others

here we go…

1. Get the courage — tell it to some experienced dudes

• I spoke with Nir Kaufman and Ori Harel which did some great tech lectures before and could give me the confidence to start and feel I know how to start
• answered the following questions before I chose the subject

What do I want people to take from the lecture?

What do I like the most?

What do I know and don’t know? Make sure before the lecture and don’t be shy to say it

Is this lecture a tutorial/inspiration/deep dive? — decide on one type help

2. Find some early adopters (or they will find you)

I had a plan that waited on Trello for a long time to approach some meetup groups and people

And than without a notice , Omri Bitan (the man!) asked me : “Hey Chen, can you do for us a React lecture one and a half month for now? Me: Oh of course!

When you get the opportunity, take it. This is the thing that will light the fire inside and everything will start happening just because you do not have a choice (:

3. Find some subjects for the lecture. Only subjects that you are passionate about!

• Write three to five main points for lecture
• Fit to the audience and context! Early stage startups? Give tips for tools to build with React faster that usual : awesome-react, NativeBase, Material-UI..find more
• Choose 2 subjects from your options that you like the most
• Share their outline with other people to get feedback (make sure they cover the target audience)
• Choose 3–5 people and send them, see what makes them interest the most and try understanding why
• After choosing one subject, make sure the objective and key point are in the beginning of the lecture (also add data about myself and my projects

4. Start building the structure and content

• Collect links, stuff to read, videos and visuals
• Choose only the ones that seem relevant
• Make a list of them in a doc and categorised them by your outline
• Create structure bullets for the lecture (they will become the slides in the end of the process)
• Fill inside each bullet some relevant data and links and materials relevant for them
• Choose from the links doc the relevant ones and past as part of the bullets

5. Find places where you can let the audience participate or being active

• What questions can you ask the audience?
• Where can you involve them in the thinking processes as part of the lecture?

For example, I did live coding with a funny emoji React website and asked them to tell me how they would build it.

6. Now everything is ready — Create the presentation!

• Each slide is a bullet unless the bullet has some sub-bullets which require some more visuals. In this case, add more slides (:
• Do not take to much care of the design at first, make it organised and paste some visuals, code pieces on the slide even it looks totally ugly. Just make it get a shape with some content

7. Dry runs! Yay!

• Put a timer and try doing the lecture talking to yourself, even if you are not ready. It is the best way to see where you are natural and where you are stuck.
• Write the timings and places you felt less comfortable and fill the gaps in your docs of the bullets and maybe add some clues in the slides (;
• Choose 2–3 relevant friends and do the lecture for them (one by one or together) . It is also fine by phone or skype as long as they see it. I got my help from two frienda who are experienced programmers Amit BenDor and Omri who know the audience of the lecture and can be very helpful
• Get feedback from them and write it.
• Change the presentation according to their feedback
• Last dry run on someone else

8. You are ready to go!

• Relax before the lecture, take some time to yourself (meditation is also great)
• Talk to someone you love or appreciate and get their positive words

9. After the lectures, don’t be shy! Get personal feedback from part of the audience. There is always a place for improvements!

I Hope I gave you some value with this post (:

Oh and here is the link to the presentation

I will be happy to get your feedback!

Although in terms of time sounded short but I did quite a bit mainly by exaggerating hours and working days and inability to say no! To things in my way and interest me.

I’ve already worked with 7 clients on a variety of projects (mobile apps, websites, bots, consulting …) and almost everyone is different from each other and the style of working with him is completely different.

Sounds good? Do not be sure ..

Being independent is not an easy choice, but it sounds very attractive at first and it’s a new world and it’s really cool, but in practice it requires a lot of features that you have or you’ll have to develop very quickly to make progress, succeed and most importantly survive.

Do not get it wrong, I’m a masochist and I love risks so I enjoy myself the more I suffer, but it’s important for me now, after half a year, to stop for a moment, look back and share things I’ve learned and maybe help others who are just starting out.

It’s enough that one person who reads it gets a value from the post, as far as I’m concerned it was worth writing it.

I have a lot to say and it will be difficult to write everything in one post so I’ll start with a post that talks mostly about customers and if it’s successful interest people I’ll write a few more (so tell me what you love or what you want me to write later .. alright?)

1. Do not compromise, especially at first.😎

The first steps you take may be what defines the initial DNA of your business. If you choose a customer type that you do not feel comfortable with or technology that you do not like or even people that do not fit you to work with as partners, you may be dragged along with it and this way of thinking of compromise once it is hard, will not go away.

Even if it means not finding a customer and income immediately, be patient, trust me. It will be worth your while to find what you have connected to.

2. Do not put all your eggs in one basket.🐣

The intention is to treat your business as an investment portfolio. You choose what percentage of risk you are prepared to take by which you make up the case. For example, in the types of customers: 50% are established companies with long-term income, 20% are start-ups, 20% are private individuals with an idea and 10% are foreign customers.

If you intend to build a portfolio that is not built on one customer or a particular type of customer, you will not crash when the customer suddenly runs out of budget, decide that the client type is not suitable or for any other reason.

It’s clear to me that from the start it’s not easy to get straight to this building, but if you’re going there, you’ll always have a look at where you are missing in your bag and know where and to whom to aim.

3. Start from close circles to reach your first customers.👨‍👩‍👧‍👧

You have great friends and have a family who loves you, know you and care about you.

Tell them in every way about what you’re doing, your vision, your challenges right now.

It’s like seeds that you plant in all sorts of fields and wait for the tree to grow and produce fruit. There is no doubt that it is not guaranteed but with a little patience, faith and that you are talented in what you do, the opportunities will come and with much more credibility that they are from people you know.

4. Be transparent with the customer from scratch in everything.😇

Each client is a kind of relationship. It may be short term and can be long term but in a healthy relationship both sides are telling each other everything. Something that worries you and may develop into a problem in the future? Share. Do you feel that you lack data and you can not continue without it? Speak now since it may not be pleasant afterwards.

Are you unhappy with any conduct? Share and be honest. No need to go into the charges. You can do everything with a good vibe so long as your intention is the same — to succeed in creating something great together.

5. If you do not have time, say no.⌛

The tendency to please everyone and not miss interesting opportunities is dangerous. You may find yourself doing a lot of projects at the same time but not keeping up with your standards without starting to work now into the night, on weekends and maybe even then you are still not satisfied. Work from the beginning on the ability to know exactly what you want and can and do not be shy from time to time to say no. Otherwise, you might even harm one of your projects unintentionally.

6. It is important to please the customer but at the same time put any boundaries from scratch.📏

When I signed on a founders agreement to establish my startup,I also made sure to note what happens in the case of divorce. This is an example of something that no one wants to talk about because it is negative and not a good vibe but once it is suddenly needed and it is not registered .. believe me you will have some complications.

There is no such thing as friends, there is no such thing as unpleasant. Write together a document that describes everything that matters to you or the client that will happen as much as possible.

Once you start working with the coordination of expectations and honesty that everyone agrees upon, every time a complication is resolved in the document and there is no need to rack your brain.

7. Always give the customer more than he asked for.♥️

You promised only service X and can give service Y without any additional costs? Do it. Both the client will enjoy and you will enjoy the smile on his face since he received something fun and good that he did not expect and gave him an additional value.

8. Take an office or an open space with people who are fun to see on a daily basis.🏢

Think it is too expensive and prefer cafes or at your house? Well it depends on your taste as well. But you’re sitting in a compound where you’re not only inspired by other people (independent like you or startups), you’re also hanging around where your customers are hanging out or their friends will get to know you and even one conversation in the kitchen to make black coffee after hummus lunch and boom, you are references by other to new clients. It does not happen just like that and is not guaranteed, but sitting in the compounds definitely increases the chances.

9. Try to understand the potential of the work ahead.🤔

Sometimes it is enough just to ask directly without being ashamed. Even if the client is super nice and an super interesting, if you do not get jobs from him after the current one and at the same time there is another client with a long continuation potential, you should know this and if you ask more, you will probably know more (and if not? At least you tried)

10. Do not bet lower than you are worth to get the job done for just satisfying the customer.💵

First of all, it is crucial that you are aware to the amount of money freelancer with similar experience earn.

A customer who understands your value, is willing to pay, and there are no such deficiencies. You just need patience and mental strength to get to them (um, and a bit of luck, too).

As in section 1 I wrote, compromising the price at first can be dragged down and create damage later on. It will be possible to get away from it but it is much more difficult if you did not create such a foundation in advance.

There is one case in which I am in favor of low prices. If you have additional benefits from the project other than payment. Suppose? Learn new technology that you are less experienced in, work with someone you really want to work with or maybe someone who is sure to turn other customers to you later on. This is your decision how to do it and there is no exact science here. Mainly intuition.

Hope you had a nice and valuable reading!

Next time I will write about the freelance journey from another angle (:

Feel free to give me some claps here (only in case I deserve it!)

I am Chen Feldman, A Tech Freelancer

Wanna sit for a coffee or chat? www.chenfeldman.com

One of the major issues preventing us from being active is the fear of failing.
We are so afraid to find out we wasted our time, disappointed our family and friends or just chose the wrong path for ourselves.

The best way to avoid being always stuck a small step before achieving your dreams or passions is to try and fail and then..try and fail again and then…yeah..try and fail again! (I wrote here on my last try and fail session)

I am not saying you cannot become a success on the first time you tried. But unfortunately this is not the reality. Most people who try achieving goals they see as over their limit, do not succeed on the first time. In the startup world there is even a very sad number I have always heard from people :90% of startups fail (And I actually think it is higher..).

Trying and failing maybe sounds smart but the important point here, is what you learn between your tries and how better you become from time to time.

Honestly? It is not so easy but I decided to write some lessons I learned from my actions in the last two years.

1. Be willing to sacrifice and do it as soon as possible

If you really believe in what you do , show yourself it is not just something you tell yourself to feel better. Invest some major amount of cash and time on it, even consider leaving your job. I believe that if you cannot do at least one of the above something that will “hurt you” , then maybe you don’t really believe in it. Time is almost the most valuable asset you have and you need to know ASAP if it’s worth spending it on this dream.

2. Be the target audience of your product

Maybe it is not a must, but as I see it, you can improve your chances to create a product that people really need and love because you love it. You can always ask yourself or people like you about your product. Worst case? You created something you enjoy using.

3. Choose a partner you would spend time with on a deserted island

As people say, startup is a roller coaster. One day you are on the way up and one day screaming on your way down. Specially on the way down, you have to know you both can survive the fall. Even when it seems impossible. In addition to that, on a lonely island you don’t just need to survive, you need to enjoy. This way your stay there will be improved. Try to find not only a partner but a real friend you appreciate and enjoy working with.

4. Always be honest with yourself and your team

It is something easy to say but hard to do. We tend to say to ourselves that things will be solved by themselves, but this is not always the case. When you feel something is wrong, say it to your team. Do it in a state of mind of trying to solve it together, don’t just throw it like a bomb, always offer a solution.

5. Never work with people who are not passionate about your startup

There are many talented and professional people who want to join you, but without passion and light in their eyes, you can really waste each other’s time. We tend to say we are a startup with limited resources so if someone wants to work with me just for equity (shares from the company), I have to say yes. I don’t actually pay and they are willing to spend their precious time. So don’t be mistaken, money is precious but time is more. If someone works on your dream without passion, the results will be influenced respectively.

6. Always free some time to help others, even when you do not have time

One of the special things in the Israeli eco-system is that people love to help each other. Be the person who help others who needs your help. It can be even a coffee for 30 minutes, a phone call or an intro to a friend. And remember, Karma is a bitch (;

7. Leave the ego aside and be open minded for help and advice from others

Listen to ANY opinion people has and try to respect it. You do not have to agree but trying to open your mind to other directions can sometimes take you to the place that you were looking for all that time. Being open for criticism is also so important! You are going to get so much of it, so be prepared.

8. Make sure you spend time with your loved ones

When working on a startup, you sleep less, your mind is always thinking about new stuff you can try, you are worried about what others in your team do. It is so easy to leave aside your hobbies, your loved ones and take them from granted. Put your loved one in first priority. They are your base when coming back home after a hard day. There is a better chance your startup is temporary than the chance they are. Take an early breakfast together, cook a surprise dinner for friends, ask for their opinion even if they are not part of the startup world..after all they are your friends (:

9. Be willing to do stuff which is not part of your responsibility

As I said before, time is your most valuable asset. When something need to be done and you do not have a team member or resources to spend on it, learn how to do it by yourself. You might do it less better but it is better than waiting decades for someone else to do it. Of course it is important to make sure you have someone in your team you trust and can do it, but until then..leave what you do and put your resources there.

10. Money from investors can buy you time but it is not a validation

This is a very tricky one. When working as first timers on a startup we can believe that we get an investment, we are in the right direction and on the way to success. If you have an idea, first validate it! Make sure people are willing to pay on it, make sure companies are willing to co-operate and spend resources on that. The best option is an investment from a potential client as a partners if you can combine them. Make this process of validation with milestones. Every couple of months there is a goal. Didn’t achieve it? Think again if you do the right thing.

11. Never stop speaking directly with your target audience

Yeah, as I mentioned it can be you but it is not enough (: You have to speak to as many users as you can and learn from them how they use or expect to use your product. Do not guess what they want , ASK THEM! If you will do it politely they might tell you.

12. Work with interns

There are so many internship programs all over the globe. People from the US, China, Israel and so much more can do an internship in your startup. They will work and be part of the team for 2+ month and if you treat them well and really care about them, they even do a great job. This is an awesome resource specially for a bootstrapped startups..believe me..I know after working with almost ten (:

13. Focus!

Your number one enemy is being like a kid in a toy store who is excited from any toy and want to buy everything. Your time is valuable and you should focus on one thing that validate your product and takes it to the next level of validation and maybe even bring you some resources to work faster. If you will fall to the trap of doing many things but non of them is good enough, you can waste your time and maybe loose the chance to achieve your startup goals and validations

14. Always give others more than what they asked

Did customers asked you for a service you provide? Surprise them and give them a bonus which is not part of the service. Did investors asked for some data and plans? give them at least 2X than what they asked. Surprise people your interact with. Give an extra service whenever you can.

Thank you for reading, I will be happy to hear and learn more from your experience and hope you got some real advice!

Clap if you enjoyed (:

Let me take you back, it started a couple of months before the decision.

I did not write about it in my previous post, but besides being open and hearing many opinions of smart people I really appreciate, I am part of an amazing group of 18 people participating in a long and personal mentoring program.

Each entrepreneur gets a personal mentor that has a lot of business experience.

I was very lucky to work with one who is an inspirational person that built more than 4 companies, some of which highly succeeded.

It’s challenging to express this through writing, but talking to someone who sees everything from a totally different angle than you, is a gift.

He can see things you don’t want to see or admit, and can ask you the questions you would never ask yourself, because the truth hurts sometimes.

When we met I soon realized that I’m falling into a bottomless pit, without knowing how to get out.

Doing such a thing without having a backup plan is very dangerous. (I love risks but… only up to a certain point)

I found myself in a situation of giving everything I have to this startup (as I said before, no income for 1.5 years until this time) and did some volunteering side projects I was passionate about.

Everything seemed great, every day I did something I love, I met new people and created deep relationships.

But what I did not realize was that I am like a kid in a toy shop who lights up from every cool toy that makes him happy.

I had to focus myself! But how can I focus? I do not want to leave anything untouched, I like all the things I do!

So a good place to start is writing a long term plan.

It can be a 3 to 5 year plan and it contains EVERYTHING including your job, where you live, who your friends are, relationships.

At the start, I thought I would never be able to write only one option, I thought maybe 2 or 3 will be more reasonable.

But since it’s you who’s writing, asking yourself honestly what you want to do and where you want to be, you know it’s the truth because no one knows you better than you, right?

This document is kind of a secret that only my wife and mentor know about (and it can be updated in the future) but the point is very clear.

After you know where you see yourself a couple of years (which is a very hard thing for us in our generation), you can get back to the present and make better decisions.

So to make a long story short, I had to clean up and organize a lot of small exciting stuff I did and enjoyed so that I can focus on one thing, working on the startup and one more thing that will provide me some income in order to survive. Yeah it is hard to do “only” 2 things but it is critical.

Oh yes, we wanted to talk about how I survived the first fall of leaving.

I did not plan to leave in those months but I had to create a channel of income.

Let me explain in 3 steps!

Step 1 — How?

1. Created google doc with all my skills that I can make an income from
2. For each skill I asked myself the following questions:
3. What do I need to do to get there? (for example: Do i need more knowledge for that? Do I have enough experience for that? Do I need to meet some people to learn from?)
4. What are the options for income there? (ways to use this skill for my purpose)
5. How much time and effort do I need to spend?
6. Income potential (per hour or a day)
7. Summarized for each skill in one line, what are the conclusions

At this stage, if you really spent time and effort, you will see the result and a final 1–2 candidates to choose from and than just take one.

Step 2 — Dig deeper

1. What kind of projects or jobs can you do with the skill you chose?
2. What are the most popular things people are looking in this field?
3. What are the ways to get to those people which are potential clients?

Step 3 — Tasks

Those questions will result in a long list and now we are almost in the final step of this process — Choosing the most relevant stuff from the previous answers and creating actual tasks from them: what to do, how to do it, people who can help with it and a due date (priority is also a good extra but not a must).

So taking you back to my processes which involved 3+ pages of writing.

I saw 5 ways to generate income but the one with most potential was the do freelance programming projects.

To do it right I created a website (www.chenfeldman.com), a business card and wrote a personal post.

A very important point is that no matter what you chose, one of the best ways to start is to let people in your social environment (close friends, family, facebook friends..) know what you decided to do and how they can help you.

Don’t forget, your friends don’t want to laugh at you, they want to help you.

At their core people are good, and nothing makes them happier than knowing they helped a friend. (and also karma is a bitch).

I won’t say that I expected all the help and offers for projects I ended up getting. It really surprised me and gave me hope.

I took the chance and after meeting almost 10 potential clients I found the 2 clients I want to work with and I am really interested in their projects for the short and maybe long term. (in one of the next posts I might tell you about all the types of different clients I met and the different processes that each type expects)

To summarize,

This process was not easy, but looking back it was amazing and really helped me learn how to be more focused.

And as you know after I left the startup, suddenly I was not scared and did not feel pressure to execute some fast plan or find a job immediately.

I already had some solid ground to land on.

Keep in mind that I am not saying you need to do more things when you have startup. On the contrary, when you have a startup do ONLY that like a beast.

But, after you feel you are falling into a deep hole for a very long time, make a plan B to save yourself from being really hurt and traumatized.

You need more power for the next adventure, right? (:

So what am I doing today?

I am a proud freelance developer, developing mobile apps, website and recently also chatbots on facebook and telegram (which is awesome!) and even started to host a podcast for programmers (:

Do you want to meet for a coffee and hear more?

I’ll be more than happy to meet and speak almost about anything!

Thanks again to Yuval Margalit and Ardon Wesly the great for helping with editing!

But something felt different that day, I still didn’t realize what that feeling was but I understood that my point of view on Guiderr (my startup) changed.

All the passion I went to sleep with every night and woke up with every morning, decreased significantly.

Suddenly, ideas and co-operations I worked on to take the startup forward seemed less relevant or less interesting.

Suddenly ,my partner impressed me less than before.

I tried to ignore that feeling because sometimes, after going to sleep and letting things settle down, they disappear or become less intense.

But I kept waking up that week with the same feeling. Nothing has changed.

On the contrary, the opposite happened and the feeling became sharper.

At that moment I understood that after 2 years of working around the clock with a lot of passion and effort, my love story with Guiderr and my partner, had ended.

Usually I am the kind of person who makes a decision with a lot of logic and analyzing behind the scenes.

I think of the advantages and disadvantages of each parameter before making the decision.

But this time it was different, I just knew that this decision was right for me.

It was like things started to connect in my head slowly until they came out as one clear insight.

Shit! What should I do now? We have just started a pivot to the chatbot field in the last two months! Potential investors and co-operations started to be more interested in us (even that is not enough) and it is even becoming more interesting from the technological and development side than before.

How will my partner and the team react? What will happen to all the code I wrote and the effort I spent?

What will my family and friends think? Did I fail? Did I waste all this time?

Those were only part of the thoughts that were running inside my head at that moment and I did not have an answer to all of them.

But, one thing was sure, I decided without wanting to decide, it was almost like someone else decided for me.

Maybe some of you know this, but when you have a startup and you meet some friends and family, they always ask : “How’s it going with your startup?”, so I couldn’t hide it too much time.

To some of them I said everything is as usual and to some that I’m considering leaving but haven’t decided yet (even though I knew i did).

So what now? How do you notify your partner?

The short answer: During a calm moment of the day and in the most gentle way you can.

The long answer: You think very well in advance how to phrase your decision in a way that will let him understand it without too many question marks. Being honest as you can be.

Try to show that you are still around and are not disappearing, you can still help, consult and even join some future meetings until things become more stable.

Break apart a partnership is a lot like a divorce (luckily enough I have no experience with that).

There are people who get hurt here and might change course due to your decision. There are kids (product, team and potential partners) who demand attention and want to keep growing in a smooth way without screwing their character after their parents broke up in a bad way.

Here, it is very important to avoid thinking only logically and technically, try to also think about what it’s like to be in your partner’s shoes at this moment. How would you react if you were in his position? What would you expect that would make you feel more calmer about the whole change?

Nothing is perfect but it is important to try.

At the end of the day, you do have appreciation for one another and a history of working together with common targets.

Another thing is that Israel is a small country where almost everyone knows everyone through 1–2 people and you really want to avoid bad mouthing each other and creating bad karma that will eventually reach different people.

So here we are, I updated my partner and we started with all the technical stuff of what to do now. Will he continue with the company by himself? Do I get a share? What share? Do I continue being involved in some way?

Those and more are very sensitive issues which can explode and become trouble in a second if not handled delicately and correctly.

During this process it’s most important that everyone stay down to earth and not escalate disagreements irrationally.

* I won’t go deeper into these processes since they are still in process.

Ok, so I made a decision, I gave notice to my partner… now what??

When you build a startup and you don’t join one that already offers salaries and has raised funds, you are more involved and your decisions carry a lot more weight from day one.

But from the other side, when you build something from scratch you can find yourself without any income for a very long time and no one can guarantee that that will change in the near future. In my case we started with 2 steps, in the first 6 months I worked all weekends, woke up early each morning and worked until late at night. After that I decided to quit my job and worked full-time on Guiderr without a salary or guarantee of success.

The problem is that you always feel that the seed investment is right around the corner and after a couple of months it doesn’t happen. But after a couple of months you get that round around the corner feeling again.

I found myself in a situation that is called “The gambler fallacy”. In short, this details a situation in which you think that one more try and 17 red will land on the roulette and you’ll win! You feel you spent a lot of time until now and your chances have increased , but that’s not necessarily true.

At some point (two months ago) I realized that I have to find some source of income. I still believed in our product and the direction we were headed, but I needed some money in order to survive the next couple of months.

The meaning of this decision is not simple, it means:

1. Less time to work on your startup
2. Investors and potential co-operations ask if you’re “All-In” and you’re faced with trying to explain to them that you took a step back in order to produce a bit of income since you cannot get it from them
3. A risk that might kill the startup

In another post I might give more details on the deep and long process I did to figure out how I could quickly generate income from 2 work days a week that would be enough to cover my monthly expenses.

But in the meantime I will just tell about the final decision itself.

I realized that only through freelance programming jobs I’ll be able to succeed achieving my current financial goals and still spend at least 3 days a week on Guiderr and this is what I did!

I started by getting clients from my immediate circle, I created a new website, a business card and the offers started to come (luckily).

Pretty fast , I got my first paying customer and the second one while learning a lot on many types of clients (another idea for a future post).

Suddenly ,after a year and a half without an income, I got some money I could put in the bank. The pressure and the uncertainty of when money will come immediately decreased.

I even enjoyed it, first time I got a check that I earned totally independently, an interesting new feeling and achievement.

Let’s get back to the decision on leaving the startup. Suddenly ,due to the freelance jobs I had soft ground to land on. Not the safest one, but in my world, safe enough.

I have to stop for a moment and make one point very clear.

If you decided to leave a startup or a company you have two options:

1. Just leave and do everything you can from that moment to make it work
2. Try to start preparing in advance for the transition, so that when you leave you’re better prepared and have more time and control to decide what to do next.

With the second option, you have less pressure to make fast decisions with an hourglass in staring you in front of your face. You decide the rhythm of your life and you can go after what you want and not what others want you to do for them.

Good! So we hurdled over the initial blow of leaving, now what?

To tell the truth, It is just the beginning and writing here is part of the understanding of the processes and letting stuff sink in and learning from them.

These days, I’m doing a freelance project (together with a friend who joined me and also recently left a startup. Kind of a support group for freelancers), I do a software podcast every two weeks that will be launched very soon and really enjoy everything and loving it.

I realize that I have just gotten off a rapid train ride, and am not in a hurry to take a new ride on a new train.

I want to feel again what’s it’s like to earn a monthly salary, how it is to work on diverse projects with diverse and different clients.

But to the people who know me, it is very clear that I do not ignore new ideas or thoughts.

I just decided that for the next couple of months I want to mainly listen around, discover new fields and meet people that can expose me to new ideas.

When the thing that will light me up again will arrive, I will use the tools I got from the startup experience and my judgment abilities and decide what to do.

To shortly summarize,

As I see it, even though my mindset was that I was building a startup for the long term and gave all I could, I found out on one sunny day that this was only one more milestone in my path through the entrepreneurial world and independent life of creating new things.

A world I am really attracted to and definitely see myself staying in and spending most of my time on.

This is the first post as part of a series of posts I plan to write on the process I went through (and went through me) and the insights I learned in my first journey to build a startup.

In the next post I will write on issues that people do not always enjoy mentioning and admitting: Failures and Mistakes.

Part of the journey contains a lot of those and people tend to avoid them. I believe that the ability to accept them ,learn from them and pass over them next time to be better, is an important skill that can be taken from here.

I will tell about some major mistakes I and we did as part of the journey from my point of view with the hope it will help others and save you time in your personal journey.

Thanks to all the people who read until here I hope you learned something new and I did not waste your time (:

* Special thanks to Yuval Margalit and Ardon Wesly for helping with the editing!